Stop allowing oc cluster up version X to instantiate a server version X-1

[jim-minter]

Although it's a cool idea to be able to instantiate previous versions of origin using a more recent oc cluster up, as complexity/distribution increases I think it's becoming untenable/expensive. Example: #15677. Without test cases, I don't see how we can guarantee correctness. I think we should draw a clear line in the sand after which oc cluster up will only instantiate servers matching its version.

@openshift/devex wdyt?

[bparees]

@hferentschik @LalatenduMohanty @gbraad (I don't think this would affect minishift since they would be expected to align the client binary and the openshift version, but we should make sure).

@jorgemoralespou as a consumer of oc cluster up, any feelings on this one way or another? Do you use a single oc binary to launch different versions? would it be a burden for you to have to use different oc client binaries to do so? (anyone else you think might have an opinion?)

[gabemontero]

So would this prevent an openshift developer from:

• building his openshift/origin local snapshot from scratch, including all images via hack/build-local-images.py
• running oc cluster up --version=latest and pick up those images built via hack/build-local-images.py

Or would part of this issues' implementation allow the equivalent by either:

• simply removing the need for --version=latest, or
• continue to support --version=latest, or
• support by supplying some special case value for --version to that local images are picked up
• or make changes to hack/build-local-images.py such that it tags the images with the local git commit level, and then that must be supplied to oc cluster up

[bparees]

@gabemontero it wouldn't prevent that. the local oc binary they just built, and the openshift binary in the images they just built, would have the same version.

passing "--version=latest" doesn't matter, we check the version by actually running the binary.

[gabemontero]

On Thu, Aug 10, 2017 at 1:39 PM, Ben Parees ***@***.***> wrote: @gabemontero <https://github.com/gabemontero> it wouldn't prevent that. the local oc binary they just built, and the openshfit binary in the images they just built, would have the same version. passing "--version=latest" doesn't matter, we check the version by actually running the binary.

cool deal

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15731 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADbadAjQCXJQXd3ISOlUiqIofSlhOS8cks5sW0BPgaJpZM4Ozng-> .

[hferentschik]

I don't think this would affect minishift since they would be expected to align the client binary and the openshift version, but we should make sure.

Well, per default we align the oc version with the baseline OpenShift version used by a given Minishift release. We used to do the same for provisioning earlier version of OpenShift. However, we switched to an approach where we use the "baseline" oc to provision earlier versions of OpenShift. There were for example issues provisioning say OpenShift 1.4 with oc 1.4. However, it works when provisioning OpenShift 1.4 with oc 1.5. So this change would indeed affect us. Let me refresh my memory on what issues we had.

[hferentschik]

For what its worth, the use case for us is to give users who for example run OpenShift 1.4 or 1.5 in production the ability to match their OpenShift version when using Minishift.

[bparees]

@hferentschik going forward, what's the use case for someone getting the minishift release from 3.7 and wanting to run 3.6 with it, instead of just getting the minishift 3.6 VM?

[LalatenduMohanty]

I think for users it wont be a blocker if we provision v3.6 from v3.6 oc binary and v3.7 from 3.7 oc binary. However I remember @jorgemoralespou mentioned that he use latest oc binary to provision older OpenShift version and I would let him explain the use-case.

[praveenkumar]

@bparees Moving forward if I download a released oc client binary after this implementation then what would happen if I use oc cluster up --version 3.6.0 assuming I have client binary as 3.7.0. Does oc client binary just ignore --version and provision 3.7 or it will just abort by saying this is not support?

In past we had issue when provisioning origin-1.4 with oc-1.4 because it didn't have proxy support and also there was a gap between the way registry expose. And quite recently we had issue provision 1.5.1 on RHEL-7.4 because of container network check and that works for v3.6.0 oc binary so in future how will address those kind of issues?

Then there is also something from CDK side which will start a ML thread.

[bparees]

For what its worth, the use case for us is to give users who for example run OpenShift 1.4 or 1.5 in production the ability to match their OpenShift version when using Minishift.

@hferentschik I don't understand why those customers can't use a version of minishift that aligns with their cluster version?

However, we switched to an approach where we use the "baseline" oc to provision earlier versions of OpenShift. There were for example issues provisioning say OpenShift 1.4 with oc 1.4. However, it works when provisioning OpenShift 1.4 with oc 1.5. So this change would indeed affect us. Let me refresh my memory on what issues we had.

If there were issues provisioning openshift 1.4 using oc 1.4, what was shipped in the "1.4" version of the CDK/minishift? That sounds like something that should have been fixed in the 1.4 stream.

Moving forward if I download a released oc client binary after this implementation then what would happen if I use oc cluster up --version 3.6.0 assuming I have client binary as 3.7.0. Does oc client binary just ignore --version and provision 3.7 or it will just abort by saying this is not support?

@praveenkumar I think we'd want to have it tell you its not supported. Frankly the version field would be a bit of a misnomer at that point. It's really indicating what image tag to pull+use (or look for locally).

In past we had issue when provisioning origin-1.4 with oc-1.4 because it didn't have proxy support and also there was a gap between the way registry expose.

and why by the time this was fixed in oc-1.5, was it still important to go back and bring up a 1.4 cluster? At that point, why wouldn't people just bring up a 1.5 cluster with the oc-1.5 binary?

Essentially by saying "you can use a oc-1.5 to get proxy configuration support on an origin-1.4 cluster" we're stealth backporting features to 1.4 that we otherwise aren't interested in backporting. If we were interested in doing that, we'd have backported the capability into the oc-1.4 binary. I realize it's a nice workaround/escape-hatch, but I don't think it's a pattern we should be encouraging. (or can afford to maintain).

And quite recently we had issue provision 1.5.1 on RHEL-7.4 because of container network check and that works for v3.6.0 oc binary so in future how will address those kind of issues?

A few options.

1. we don't move the CDK to a version of rhel(or other dependency) that doesn't work for oc next time. If it's too late to get the fix into oc (as it was this time) then the CDK doesn't move up.
2. again, once there is a 3.6 binary available, you use it to run 3.6 clusters. If you want to run 1.5, you use the 1.5 binary, which would be part of the v1.5 CDK/minishift, presumably, no?

Today there's no guarantee that the 3.6 oc binary we just shipped, will actually work to bring up a 1.4 cluster. As @jim-minter noted, no one is testing that, and frankly we can't afford to test all those permutations (which grow each release). If it's not broken today, it almost certainly will be someday.

The current implied promise that any given oc binary can bring up an oc cluster on any version (newer or older than the binary itself) is simply not sustainable.

[gbraad]

I agree with @bparees, as provisioning an older or even a newer version, can cause very unexpected side effects. This is not a use-case you want to support. I understand how this can affect CDK, but in that case they would have to accept a download (related to 2. as they binary for a previous version is not embedded/included).