Update base slave oc version

[m-apsolon]

From 3.0.6 to 3.11.43

[clemensutschig]

flaggin as both - as with 3.6 and nodejs - there seems a path issue with tar.go fixed with 3.11

[michaelsauter]

Hmm, I thought a little about this, and I'm not sure this is the right fix.

I think we need to answer a few questions first:

• Why is the default 3.6? Is that random, or are we using an old base image?
• What happens to users of ODS running an OpenShift version before 3.11?

Maybe we should either "fix" the base image or make this configurable?

[michaelsauter]

OK, so doing a bit of research on this ... I discovered the following:

The Dockerfile of our slave-base image (https://github.com/opendevstack/ods-core/blob/1.0.x/jenkins/slave-base/Dockerfile.rhel7) has this FROM instruction:

FROM registry.access.redhat.com/openshift3/jenkins-slave-base-rhel7

So it points to the latest tag, which at the time of writing is equal to the v3.6.173.0.146-3 tag of that image (see https://access.redhat.com/containers/?tab=tags#/registry.access.redhat.com/openshift3/jenkins-slave-base-rhel7). Why this is the case I have no idea, there are also newer images, e.g. v3.11.82-4 which is what we would want.

In the end, to have matching versions, one could configure the tag to use in the ods-configuration, and then we put that in the BuildConfig so that the FROM clause is not actually used but replaced with what is in the BuildConfig. See e.g. https://github.com/opendevstack/ods-core/blob/master/shared-images/ocp-config/bc.yml#L66-L68.

[michaelsauter]

This seems to work for us:

spec
  strategy:
    dockerStrategy:
      from:
        kind: DockerImage
        name: 'openshift3/jenkins-slave-base-rhel7:v3.11'

[michaelsauter]

I would tentatively leave this master-only and not merge it into 1.0.x because:

• The problem is an OpenShift issue (they forgot to update the image tags)
• Putting this into 1.0.x would require users to update their config, and if they upgrade ODS without that step, it could break the existing setup ...

@clemensutschig Agreed or do you want this in 1.0.x?

[clemensutschig]

1.1 .. :) is this fixed now? @michaelsauter

[michaelsauter]

Yes fixed in 1.1, see PR: #91