Bug 1780622

Karel - I just git cloned https://github.com/kiegroup/kogito-examples and I do not see a .s2i directory anywhere 
nor a image_metadata.json file anywhere.

Was it recently updated, or was it missing all along?

@Gabe,

This file is generated during the s2i chain build. We first have the binary generated by builder image [1] and then we generate the runtime image [2] that has the image_metadata.json file copied to (/tmp/.s2i/image_metadata.json) [3]

To try it locally, try:

~~~
$ pwd
~/kogito-examples/onboarding-example/hr
~~~

~~~
s2i build . quay.io/kiegroup/kogito-quarkus-ubi8-s2i:0.6.0-rc3 hr-service --runtime-image quay.io/kiegroup/kogito-quarkus-jvm-ubi8:0.6.0-rc3 -e NATIVE=false
~~~ 

Will take some time, if you have a Maven mirror set the variable MAVEN_MIRROR_URL.

The final image has the labels mentioned by Karel because we're running locally via s2i tool.

~~~
$ docker inspect hr-service | grep prometheus 
                "prometheus.io/path": "/metrics",
                "prometheus.io/port": "8080",
                "prometheus.io/scheme": "http",
                "prometheus.io/scrape": "true",
~~~


[1] https://github.com/kiegroup/kogito-cloud/blob/master/s2i/kogito-quarkus-s2i-overrides.yaml
[2] https://github.com/kiegroup/kogito-cloud/blob/master/s2i/kogito-quarkus-jvm-overrides.yaml
[3] https://github.com/kiegroup/kogito-cloud/blob/master/s2i/modules/kogito-s2i-core/added/s2i-core#L31-L33

OK that clarification helps Ricardo.  And to start, it definitely falls under the category of "different scenario" from an s2i perspective than what is captured in https://bugzilla.redhat.com/show_bug.cgi?id=1758305

And in fact falls outside the realm with what is currently supported with this image_metadata.json file.

Perhaps the documentation at https://github.com/openshift/source-to-image/blob/master/docs/new_labels.md needs to be clarified further, but the assumption is that is part of the git repo that is cloned prior to build 
execution, whether with the original s2i form and the post execute step, or the changes I added for dockerfile generation with https://bugzilla.redhat.com/show_bug.cgi?id=1758305

Once you have started build execution, I do not believe trying to update content at the /tmp/.s2i level at assemble time like you are doing at https://github.com/kiegroup/kogito-cloud/blob/master/s2i/modules/kogito-s2i-core/added/s2i-core#L31-L33
is allowed.

I believe we are talking a new feature request to make it work (and again, perhaps clarifying the doc at https://github.com/openshift/source-to-image/blob/master/docs/new_labels.md short term).


But certainly Adam and Ben on cc: here can keep me honest.

Thanks, Gabe!

But this works on OCP 3.11. Indeed we used this doc [1] to write our images. We assumed that after the first build, the second one would take the file and write to the image metadata as the s2i process do in 3.11.

I think the original BZ resolution misunderstood the purpose of https://github.com/openshift/source-to-image/blob/master/docs/new_labels.md

The idea was that you can, as part of your assemble script, dynamically generate additional labels you want applied to the output image.  So your assemble script writes out a /tmp/.s2i/image_metadata.json file, and then s2i would detect that file and apply the labels it defined to the output image.  The point being to generate a label that might indicate what maven version of a particular package was installed during this particular build, for example.

It looks like https://bugzilla.redhat.com/show_bug.cgi?id=1758305 just allowed for the definition of static labels in the source repo.  (something it was basically already possible to do using buildconfig.spec.output.imageLabels, essentially, though it would require updating a resource that wasn't necessarily stored in the git repo).

To make this work in OCP4 the way it worked in OCP3 (I think we added this feature for OSBS but i can't remember for sure), is quite honestly probably not (reasonably) possible.  It would require us being able to generate a dockerfile that could detect if an image_metadata.json was created, read it, and then generate additional LABEL commands(that would have to be part of the Dockerfile we were already in the middle of building).  But there's no way to dynamically add LABEL commands to the dockerfile that i'm aware of.

I also think we should revert https://bugzilla.redhat.com/show_bug.cgi?id=1758305 before it ships in 4.3 (assuming it hasn't already been backported and shipped somewhere) because it's introducing a new behavior that i don't think we want to introduce/support, at least not without more thought.

tldr:

> Once you have started build execution, I do not believe trying to update content at the /tmp/.s2i level at assemble time like you are doing at https://github.com/kiegroup/kogito-cloud/blob/master/s2i/modules/kogito-s2i-core/added/s2i-core#L31-L33
is allowed.

is exactly the original purpose of /tmp/.s2i/image_metadata.json though again i'm struggling to think of how we can implement that behavior in v4 given that we are now dockerfile based and have less dynamic control over the image generation/metadata.

Hi Ben! Many thanks for your detailed reply.

Looking at the customer/user perspective, if they rely on this in v3, we should support the feature or document it somewhere that we do not support it any more giving them alternatives, don't you think? Sorry if we already have this documented somewhere. Your solution of using `buildconfig.spec.output.imageLabels` seems reasonable to me and MIGHT work for us. I have to think more carefully about it.

> Looking at the customer/user perspective, if they rely on this in v3, we should support the feature or document it somewhere that we do not support it any more giving them alternatives, don't you think?

yes, absolutely.  We missed/overlooked this feature when we were migrating how s2i builds worked from v3 to v4.  The BZ was then (correctly) reported observing that fact: https://bugzilla.redhat.com/show_bug.cgi?id=1758305

Ideally we'd have fixed that bug and re-enable the feature but in this case the BZ was not fixed correctly(due to a misunderstanding of what the broken feature was supposed to be doing) and fixing it correctly is, as I noted earlier, extremely complicated to the point of potentially not being reasonably possible.  In which case yes, we need to fix our documentation to make it clear that the s2i feature(as it works with the s2i command line) is not supported when using s2i in openshift (or when using "s2i --as-dockerfile" for the s2i cli, for that matter).

With the revert requested (and subsequent docs update) by Ben, we'll drive this via https://bugzilla.redhat.com/show_bug.cgi?id=1758305 ... closing this as a dupe

*** This bug has been marked as a duplicate of bug 1758305 ***

Actually I'll use this bug as the 4.4 bug I need to navigate our wonderful process

ok the bugzilla bot is being difficult.

opening a new bug(s) to make it happy

*** This bug has been marked as a duplicate of bug 1758305 ***