add clarification around oc version and image tags #486
Conversation
openshift-ci-robot
added
the
size/M
README.md
Outdated
| --------------------------------- | ||
|
|
||
| To assist in interacting with the OpenShift API server while using this image, the `oc` binary, the CLI command for OpenShift, has been | ||
| installed in this image. |
There was a problem hiding this comment.
installed in the master and slave images defined in this repository.
README.md
Outdated
| To assist in interacting with the OpenShift API server while using this image, the `oc` binary, the CLI command for OpenShift, has been | ||
| installed in this image. | ||
|
|
||
| However, it needs to noted that backward compatibility is not guaranteed between different versions of `oc` and the OpenShift |
README.md
Outdated
| policy used is warranted to guarantee consistency around what image is being used on each of your nodes. | ||
|
|
||
| **Notice: the `latest` tag for the RHEL7 images will point to 3.6 for the time being in order to support users whose pull policies for | ||
| their Kubernetes Plugin configuration lack the "pull always" setting. This way, they will have an older `oc` client which should be able to |
There was a problem hiding this comment.
it's unrelated to pullalways. The rhel7 images point to the 3.6 tag (not just for the time being but probably forever) to ensure users on older clusters and who have older slave configurations that point to ":latest" will continue to work (will continue to pick up the v3.6 oc binary).
New slave configurations use version specific tags (as well as pullalways) to ensure the right image is used for their cluster.
There was a problem hiding this comment.
I was trying to be as non-committal as possible wrt "time being" vs. "probably forever"; just seemed rash to say "forever"... perhaps just remove the "time being" phrase and not substitute any other indication of time frame ?
otherwise sure I'll remove the pull always piece, just reference "to ensure users on older clusters and who have older slave configurations that point to ":latest" will continue to work (will continue to pick up the v3.6 oc binary)."
There was a problem hiding this comment.
Maybe "indefinitely" or "for the foreseeable future" instead. "For the time being" implies to me that we have plans to change it at some point when we get to it, which we don't.
There was a problem hiding this comment.
I'll go with indefinitely
README.md
Outdated
| | :-------------------------- | ------------------------ | | ||
| | `jenkins-*-centos7:v3.7` | 3.7 `oc` binary | | ||
| | `jenkins-*-centos7:v3.6` | 3.6 `oc` binary | | ||
| | `jenkins-*-centos7:latest` | 3.9 `oc` binary | |
There was a problem hiding this comment.
I think that if you state 3.9 here, it'll need to be changed next release. Might be better to say "whatever the latest version is" (or words to that effect)?
There was a problem hiding this comment.
Sure ... it is literally "the version of oc present in the docker.io/openshift/origin:latest image at the time the jenkins images with the latest tag were built".
I'll work on some consumable form of that. Suggestions are of course welcome.
README.md
Outdated
| | `jenkins-*-centos7:latest` | 3.9 `oc` binary | | ||
| | `jenkins-*-rhel7:v3.7` | 3.7 `oc` binary | | ||
| | `jenkins-*-rhel7:v3.6` | 3.6 `oc` binary | | ||
| | `jenkins-*-rhel7:latest` | 3.6 `oc` binary | |
There was a problem hiding this comment.
Might be worth reversing the two paragraphs that follow and putting an asterisk here to link the following paragraph more closely
There was a problem hiding this comment.
I imagine there is some trick with markdown language to employ the asterisk like you are suggesting .... unless you know different, I'll start hunting for examples / doc references
|
response to comments pushed in separate commits |
README.md
Outdated
|
|
||
| **Notice: There is an additional consideration with the pod configurations for the Kubernetes Plugin; earlier versions of this image | ||
| did not specify the "pull always" policy for the default agents/slaves configured. As a result, users may have older/different images on | ||
| your nodes depending when the images were pulled. Staring with the 3.7 release, the default changed to "pull always" to avoid this problem |
|
one last nit and lgtm |
|
thanks @bparees I'll give @jim-minter some time before squashing and merging |
|
lgtm |
|
[merge] |
|
Evaluated for jenkins merge up to ff4523e |
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_jenkins_images/94/) (Base Commit: 40b6428) (PR Branch Commit: ff4523e) (Image: devenv-rhel7_95) |
Fixes #477
@openshift/sig-developer-experience ptal