Comments (21)
@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.
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.
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.
I would agree that this is intended and fine as is.
from ods-core.
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.
so, is this really a bug or a bad naming convention from redhat?
from ods-core.
@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.
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.
or instead 3.11 to latest
from ods-core.
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.
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.
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.
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.
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.
@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.
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.
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.
I like it, then this would mean working over:
- ods-core - to make a note on the affected FROM statements and define there the centos related ones
- ods-core - to change the related ocp-configs
- 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.
@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.
@michaelsauter - this is now fixed in ODS 3 - close?
from ods-core.
Yes this has been fixed by #544.
from ods-core.
Related Issues (20)
- periodically build and publish jenkins-agent-base HOT 1
- outdated snyk version in ci workflow HOT 1
- outdated helm version in Jenkins base agent
- Outdated git-lfs version
- CI Workflows error out on Ubuntu 18 use
- Removal of Centos and deprecation of ODSBox HOT 2
- SonarQube maintenance
- Update and align Aqua version with cli
- SonarQube Rust support
- webhook proxy feature for jenkins idling HOT 1
- Jenkins maintenance
- auto-update (PR) github actions
- tests/go.mod,go.sum maintenance
- Trivy into Jenkins Agents
- Nexus maintenance
- Error adding ALLOWED_CHANGE_REF_TYPES as env variable HOT 2
- Configuration mismatch on Prov-app and ods-core repositories
- Webhook proxy BC recretion issues
- SonarQube PostgreSQL backup
- Glibc package install isues on Jenkins agent HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ods-core.