jenkins master / slave base bc FROM points to jenkins:2

[clemensutschig]

    strategy:
      type: Docker
      dockerStrategy:
        from:
          kind: ImageStreamTag
          name: jenkins:2
          namespace: openshift

this seems pretty odd ?! no?

[gerardcl]

hi @clemensutschig , this is fine since this is the tag/version we want to use --> https://github.com/openshift/jenkins/tree/master/2

[michaelsauter]

I would agree that this is intended and fine as is.

[clemensutschig]

interesting - I thought it would be openshift/jenkins-2-rhel7 - which also contains the latest 3.11? ...
(and is also what the from in dockerfile says BTW ..)

https://github.com/opendevstack/ods-core/blob/master/jenkins/master/Dockerfile#L1

[gerardcl]

so, is this really a bug or a bad naming convention from redhat?

[clemensutschig]

@gerardcl - I think this is a bug ... because from imagestream in the BC should mirror FROM in dockerfile .. (which it does NOT)

[gerardcl]

so, to be precise, after testing:
master jenkins base image bc shold be like:
from:
kind: ImageStreamTag
name: 'jenkins-2-rhel7:3.11'
namespace: openshift

and jenkins slave base image bc should contain:
from:
kind: ImageStreamTag
name: 'jenkins-slave-base-rhel7:3.11'
namespace: openshift

[clemensutschig]

@gerardcl - can you open a ticket with redhat - and ask what we should point to ... imagestram / image name - e.g. latest :)? or ...

[gerardcl]

or instead 3.11 to latest

[gerardcl]

from RH answer we have been pointed on comparing through:

$ oc get istag jenkins:2 -n openshift 
$ oc describe istag jenkins:2 -n openshift

Once compared with jenkins-2-rhel7 they are both pointing to same URL image path so this means they are both the same, and jenkins one seems an alias.
Then, the naming that appears in all clusters is the openshift/jenkins one and the openshift/jenkins-2-rhel7 is not everywhere.
So, as a first conclusion we should keep using jenkins:2 for now, but we still need to know if it is better to point to latest tag, indeed we see following tags: 2, 3.11 and latest...

I'm waiting for more clarifications from RH in order to know why there is this alias and which is the rightest tag to use...

Regarding the tag topic I would recommend to stick/fix a version and just upgrade it in a per ODS upgrades (testing it before) so we assure in all ODS deployments using same version they are also using same jenkins versions

[gerardcl]

then, regarding jenkins slave images, we need to agree which build from configuration we want to use, we have different options here and maybe we could also align this with the jenkins master one.
the options are "build from image stream tag" or "docker image". Last one is more flexible since you can point to a specific registry too.

[gerardcl]

ok, latest message from RH:

Given that you want to be very specific in which image you want to use, it is probably best to be explicit by specifying : rather than using the abstraction of the imagestreamtag of "jenkins:2". Do not use the "latest" tag as due to historical reasons this is locked to the "v3.6" image for OpenShift clusters on version 3.6 and lower. From OpenShift 3.7 and higher the jenkins image tag should match the cluster version, so with cluster being at vX.YY, this is the tag you should be using assuming your version matches.

So, definitely we should stop using the alias "jenkins" and move to the right image:tag and by tag matching cluster version.

Now, waiting for an answer for if it would be better to build from a docker image instead of image stream tag...

[gerardcl]

Ok, from RH answers we can conclude:

• To use imagestreamtag: so to keep using jenkins:2 imagestreamtag and expect that at OCP cluster upgrade events the matching is mantained.
  ..or..
• To use docker image: so to use docker image "registry.redhat.io/openshift3/jenkins-2-rhel7:" path and apply tag value from a configuration parameter that matches OCP version being used.

RH answer:

There is no "jenkins-2-rhel" imagestreamtag, "jenkins-2-rhel" refers to the actual docker image. [1][2] There is only the "jenkins:2" imagestreamtag which is an abstraction that eventually points to some particular "registry.redhat.io/openshift3/jenkins-2-rhel7:" image, in this case "registry.redhat.io/openshift3/jenkins-2-rhel7:v3.11". [3]
The particular image an imagestream tag points to can change over time as the cluster is upgraded.

In order to use the "jenkins:2" imagestreamtag and have the same result on both clusters, you will need to keep one cluster version of OCP matching the other cluster version of OCP.
If one cluster upgrades ahead of the other cluster then use the docker image version instead.

As these are independent clusters managed by independent teams, it is simply not possible to expect imagestreamtag version parity with independent upgrade schedules.
[1] https://docs.openshift.com/dedicated/architecture/core_concepts/containers_and_images.html#docker-images
[2] https://docs.openshift.com/dedicated/architecture/core_concepts/builds_and_image_streams.html#image-stream-tag
[3] https://github.com/openshift/openshift-ansible/blob/release-3.11/roles/openshift_examples/files/examples/x86_64/image-streams/image-streams-rhel7.json#L105-L116

[gerardcl]

Hi @clemensutschig and @michaelsauter which are your thoughts? shall we keep pointing to jenkins:2? or shall we change and manage through docker image tag right pointing?

[gerardcl]

@clemensutschig and @michaelsauter which are your thoughts? shall we keep pointing to jenkins:2 so to use an alias managed? or shall we change and manage through docker image tag right pointing?

[michaelsauter]

With #91, the slave image already uses DockerImage and configuration, so for consistency, we could use that for the master image, too. That said, I think in general this is more of a cluster concern and should be made correct there ... the thing is, the value has to be changed at the time of a cluster upgrade, which normally does not require you to touch ODS.

[gerardcl]

hi! I detected that using DockerImage out of a non RHD cluster this is not working (not found) but what is always working is jenkins:2 which is anyway an alias of the right image...

[rattermeyer]

Yes, this is a concern. Currently considering how to solve #167 so that it works for OKD and OpenShift. Proposal: The DockerImage itself should reference to the correkt OpenSource Version, like FROM openshift/jenkins-2-centos7:v3.11 This allows building and testing the image on any developers laptop (no need to have a subscription).

The from in the bc can override the FROM from the dockerfile (find this strange, but in this case it makes some sense).

      type: Docker
      dockerStrategy:
        from:
          kind: ImageStreamTag
          name: jenkins:2
          namespace: openshift

and make the name a variable. Which defaults to jenkins:2

[gerardcl]

I like it, then this would mean working over:

1. ods-core - to make a note on the affected FROM statements and define there the centos related ones
2. ods-core - to change the related ocp-configs
3. ods-configuration-sample - to make it configurable (aligning with ods-core changes)

@rattermeyer am I missing something?

@michaelsauter @clemensutschig shall we proceed with this?

[michaelsauter]

@rattermeyer I agree that we should point to centos. However, we cannot put a OKD version number into the Dockerfile as we cannot know which version to use - 3.11 would be just an assumption. For me it has to default to FROM openshift/jenkins-2-centos7.

[clemensutschig]

@michaelsauter - this is now fixed in ODS 3 - close?

[michaelsauter]

Yes this has been fixed by #544.