FMP and JIb integration

[devang-gaur]

Jib (Java Image Builder has recently been integrated as an option for container image building. Earlier Docker (via Docker Maven Plugin) used to be the only option for building images.

Since Jib does the image build and push to the container registries on its own, the current integration has been structured such as fabric8:build goal does both build and push task (Omitting fabric8:push goal from the developer flow). If the user's machine is offline, a local .tar image is built locally.

However, this deviates from the framework that FMP originally aimed for the user to adapt, i.e., fabric8:build (build a local .tar image) and fabric8:push (push the built image to the configured registry). Docker-based builds follow this flow.

So, there has been a discussion going around the team (@rohanKanojia @manusa @dev-gaur ) maintaining the fabric8 maven plugin currently to reconsider and refactor the way Jib integration works in FMP (mostly to make Jib workflow the same as Docker's, just without a daemon) and we're looking for opinions of ours users and the involved stakeholders regarding what would be the right way of taking things forward

Therefore, please comment down what you think should be done.

@burrsutter @kameshsampath @cmoulliard @iocanel @oscerd @geoand @hrishin @piyush-garg @ro14nd @oskutka @jorgemoralespou

Apologies, if this feels like spam.

[jorgemoralespou]

@dev-gaur plugin needs to be consistent in the workflow/experience provided, even if that means assuming some complexity in the plugin internals. We can't sacrifice user experience for technical simplicity as that will drive users away.

[geoand]

I would say that consistency is important, so yes I would expect the workflow to be the same in both cases.

[rhuss]

IMO we should keep the workflow and semantics the same as for other build mechanisms. @rohanKanojia did this build/push separation for the docker-maven-plugin already, so this could be taken over directly. Also, there are different concerns e.g. when it comes to authentication, and the fabric8:build goal would have to deal with registry authentication for JIB mode. However all the machinery (like the props to configure) is in the fabric8:push mojo, so this is another reason to keep that build/push separation also for JIB (even if this means that we have to store an intermediate tar artefact). Push needs to be extended to select whether its a Docker push or whether its about talking to a registry directly. Having these two different push modes is also beneficial if additional, docker-less build mechanism should be included which also require a direct push (and not indirectly via a Docker daemon).

[devang-gaur]

Also, there are different concerns e.g. when it comes to authentication, and the fabric8:build goal would have to deal with registry authentication for JIB mode.

Yeah, I implemented it that way... such as Registry Authentication also happens within fabric8:build
for JIB mode, and it looks ugly there.

I'll make the required changes. Thanks, everyone for their views!

[erikgb]

This issue (question) may be relevant: GoogleContainerTools/jib#2104

I was hoping to prepare a pull request fixing this f-m-p issue, but I do not have time now. Awesome if @dev-gaur could prepare something. I would be happy to provide review/comments...

[rohanKanojia]

Thanks @erikgb , I'll add you for review :-)

[seboudry]

Hi guys !
Any update considering this build/push separation in JIB mode?

Happy 2020 ;)

[rohanKanojia]

@seboudry : There is a PR already #1766 . I think we should prioritise getting it merged before releasing 4.4.0

[devang-gaur]

Closing since #1766 has been merged.