Question: image trigger on a build configuration

[littlebigfab]

Hi,

I'm studying DO425. In guided exercise 3.2, we add an image trigger on a build configuration. The corresponding image stream is/jboss-eap71-openshift is in the openshift namespace which is not the current one.

[student@workstation openshift-tasks]$ oc set triggers bc openshift-tasks \
--from-image='jboss-eap71-openshift:latest'

First, I don't understand why we don't prefix the image stream name by the namespace openshift/. I tried to do so but it doesn't work : an image trigger is effectively added to the bc, but with no associated image stream reference.

The help page gives this example though:

  # Add an image trigger to a build config
  oc set triggers bc/webapp --from-image=namespace1/image:latest

Second, I don't clearly understand the 'latest' tag in those commands. Does it mean that the image stream must comprise an image with the 'latest' tag, or rather, that any new image imported to the image stream is going to trigger the re-build ? What confuses me is that that tag is mandatory in the command.

Thanks in advance for your insights :)

[oldbenko · Accepted solution]

Hey, @littlebigfab,

A great question!

So, for those who don't know where and what is happening - this is about the first Guided Exercise in Chapter 3 (Implementing Security in the Build Process), called Performing a Source-to-Image Build Process.

This exercise is trying to showcase two things:

• how a build hook can be used to verify a build after it finishes
• how image streams can automatically trigger builds when a new base image is available

The former is achieved by adding a new profile to pom.xml and use a special Maven command to activate this profile after the new container image has already been built, but before it's been pushed into the internal image registry. Nothing tragic here.

In the process of setting everything up, the oc new-app command is used to create all the resources, including the BuildConfig which we end up modifying a couple of times.

Initially, this BC is configured to use the openshift/jboss-eap71-openshift:latest ImageStreamTag to perform the build. At the same time, an ImageChange trigger monitoring the same ImageStreamTag is automatically created. It is used to automatically start the build if the base image changes. All according to the rulebook up to here, except that it would probably be a better idea to show that prior to moving on:

$ oc set triggers bc/openshift-tasks
NAME                          TYPE     VALUE                                   AUTO
buildconfigs/openshift-tasks  config                                           true
buildconfigs/openshift-tasks  image    openshift/jboss-eap71-openshift:latest  true
buildconfigs/openshift-tasks  webhook  <secret>
buildconfigs/openshift-tasks  github   <secret>

The way I see it, there are two directions we could take it from here on. Either leave everything as it is and skip the oc set triggers command in step 4.1, or proceed as I suggest below.

The confusing bit about step 4.1 is that we actually add a new trigger using the following command:

$ oc set triggers bc openshift-tasks --from-image=jboss-eap71-openshift:latest
buildconfig.build.openshift.io/openshift-tasks triggers updated

In itself, and in present state of affairs, this step is completely redundant. It could only serve as a demonstration of how one can create an ICT if one did not yet exist. What has additional potential for confusion is also that the exercise fails to clearly demonstrate in the printed output, that the old ICT has not changed, and we instead have a new one:

$ oc set triggers bc/openshift-tasks
NAME                          TYPE     VALUE                                   AUTO
buildconfigs/openshift-tasks  config                                           true
buildconfigs/openshift-tasks  image    openshift/jboss-eap71-openshift:latest  true
buildconfigs/openshift-tasks  image    jboss-eap71-openshift:latest            true
buildconfigs/openshift-tasks  webhook  <secret>
buildconfigs/openshift-tasks  github   <secret>

(Yes, BCs can monitor more than one image at the same time! This is very useful for staged pipelines which perform multiple builds/tests and may need to be re-run for any number of reasons.)

Finally, the skopeo copy command doesn't help, because if we really wanted to make use of the new trigger we added above, it should go something like this:

$ oc whoami -t
XXXX...XXXX
$ skopeo copy --dest-tls-verify=false \
        --dest-creds developer:XXXX...XXXX \
        oci:./eap71-openshift-1.3-17/ \
        docker://docker-registry-default.apps.lab.example.com/build-s2i/jboss-eap71-openshift:latest

Notice the registry URL above. Skopeo is pushing the image into your own project! This implicitly creates a new image stream (incidentally, the one that the BC is now monitoring):

$ oc get is
NAME                    DOCKER REPO                                                        TAGS      UPDATED
jboss-eap71-openshift   docker-registry.default.svc:5000/build-s2i/jboss-eap71-openshift   latest    2 seconds ago
openshift-tasks         docker-registry.default.svc:5000/build-s2i/openshift-tasks         latest    6 minutes ago

And of course, it starts a new build, too:

$ oc get pods
NAME                      READY     STATUS            RESTARTS   AGE
openshift-tasks-1-build   0/1       Completed         0          8m
openshift-tasks-1-xbj75   1/1       Running           0          6m
openshift-tasks-2-build   0/1       PodInitializing   0          5s

Thanks for pointing this out - I'll check our training feedback site if there's something about this there already and create it if there isn't.

Finally, about the ImageStreamTag that's confusing you.

Notice that the jboss-eap71-openshift image stream in the openshift project is a collection of ImageStreamTags:

$ oc describe is -n openshift jboss-eap71-openshift
Name:			jboss-eap71-openshift
Namespace:		openshift
...
Unique Images:		1
Tags:			4

latest
  tagged from registry.lab.example.com/jboss-eap-7/eap71-openshift:latest
...
  * registry.lab.example.com/jboss-eap-7/eap71-openshift@sha256:c04abb1429f092a6f1bf7e936bb8faea30908e43850fb5f6de0fcdbb5f4ba363
      6 months ago

1.3
  tagged from registry.lab.example.com/jboss-eap-7/eap71-openshift:1.3
...
  * registry.lab.example.com/jboss-eap-7/eap71-openshift@sha256:c04abb1429f092a6f1bf7e936bb8faea30908e43850fb5f6de0fcdbb5f4ba363
      6 months ago

1.2
  tagged from registry.lab.example.com/jboss-eap-7/eap71-openshift:1.2
...
  ! error: Import failed (NotFound): dockerimage.image.openshift.io "registry.lab.example.com/jboss-eap-7/eap71-openshift:1.2" not found
      6 months ago

1.1
  tagged from registry.lab.example.com/jboss-eap-7/eap71-openshift:1.1
...
  ! error: Import failed (NotFound): dockerimage.image.openshift.io "registry.lab.example.com/jboss-eap-7/eap71-openshift:1.1" not found
      6 months ago

Nevermind that the latter two aren't found (it's just because we don't have them in our classroom) - they are still istags in their own right, each with its own registry URL, image metadata and history.

To be able to differentiate between them though, the name of an imagestream is foo, and the name of an imagestreamtag is foo:bar, denoting it belongs to IS foo.

Try describing an istag using oc describe istag -n openshift php:latest - you'll see it contains a ton of interesting stuff which looks nothing like the IS itself.

The relationship between an is and an istag is therefore that the former is a collection of zero or more of the latter, and because each istag can have its own, completely different, registry URL, this makes the is a brilliant tool to catalogue related images together, regardless of where they're coming from.

Additionally, an istag (for example prod) can be a symbolic pointer to another istag (for example 1.4), and can serve as a convenient way to promote a new version of an app to a staging area with little hassle, similarly to how physical image tags can be reassigned at will.

I hope this answers your question about tags - if there's anything else I can help with, I'll be happy to!

Cheers,
Grega

[littlebigfab]

Thank you so much @oldbenko ! :)

[littlebigfab]

Hi @oldbenko,

I just did this guided exercise again, following your suggestion and updating the image stream in the build-s2i namespace, thus calling the trigger we've actually set up, instead of the default one.

Not only did all of your commands work like a charm, but it was also very instructive. Thanks again :)

[oldbenko]

Hey, @littlebigfab, my greatest pleasure, dear Sir! :smileyvery-happy: