Giter Site home page Giter Site logo

Comments (21)

clemensutschig avatar clemensutschig commented on August 10, 2024 1

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

from ods-core.

rattermeyer avatar rattermeyer commented on August 10, 2024 1

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

from ods-core.

gerardcl avatar gerardcl commented on August 10, 2024

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

from ods-core.

michaelsauter avatar michaelsauter commented on August 10, 2024

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

from ods-core.

clemensutschig avatar clemensutschig commented on August 10, 2024

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

from ods-core.

gerardcl avatar gerardcl commented on August 10, 2024

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

from ods-core.

clemensutschig avatar clemensutschig commented on August 10, 2024

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

from ods-core.

gerardcl avatar gerardcl commented on August 10, 2024

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

from ods-core.

gerardcl avatar gerardcl commented on August 10, 2024

or instead 3.11 to latest

from ods-core.

gerardcl avatar gerardcl commented on August 10, 2024

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

from ods-core.

gerardcl avatar gerardcl commented on August 10, 2024

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.

from ods-core.

gerardcl avatar gerardcl commented on August 10, 2024

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...

from ods-core.

gerardcl avatar gerardcl commented on August 10, 2024

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

from ods-core.

gerardcl avatar gerardcl commented on August 10, 2024

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?

from ods-core.

gerardcl avatar gerardcl commented on August 10, 2024

@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?

from ods-core.

michaelsauter avatar michaelsauter commented on August 10, 2024

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.

from ods-core.

gerardcl avatar gerardcl commented on August 10, 2024

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...

from ods-core.

gerardcl avatar gerardcl commented on August 10, 2024

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?

from ods-core.

michaelsauter avatar michaelsauter commented on August 10, 2024

@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.

from ods-core.

clemensutschig avatar clemensutschig commented on August 10, 2024

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

from ods-core.

michaelsauter avatar michaelsauter commented on August 10, 2024

Yes this has been fixed by #544.

from ods-core.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.