oc cluster up --service-catalog=true uses canary service catalog images

[spadgett]

There are some API breaking changes coming to service catalog. In the near term, pod presets for bindings is changing, but there might be other breaking changes down the line. If we continue to use the canary images, the catalog will likely be broken later when run with the 3.6 console.

@bparees @jwforres @pmorie @csrwng

[bparees]

are the canary images not going to get those updates?

[jwforres]

they are, that is the concern, someone trying out the 3.6 origin release with --service-catalog and they get the canary service catalog images, that won't work with the 3.6 console

…

On Mon, Jul 17, 2017 at 12:39 PM, Ben Parees ***@***.***> wrote: are the canary images not going to get those updates? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15237 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABZk7bcP5CNgjIWajnatDKSxdTMnJCfrks5sO40NgaJpZM4OaIEt> .

[bparees]

@jwforres so is the SC team going to tag an image level that we can lock against for now? this is going to be an on-going pain point until the SC api is stable/compatibility-guaranteed.

I really don't want to add a "--service-catalog-image-tag" flag to oc cluster up.

[bparees]

/cc @derekwaynecarr

[jorgemoralespou]

@bparees related to this: #15243 (comment)

I don't think adding flags should be the way forward when we have image tagging support on the registries. Even if in this case the images are not ours, we could use an ImageStream to abstract that.

[bparees]

Even if in this case the images are not ours, we could use an ImageStream to abstract that.

we could certainly define an imagestream within the service-catalog template and then define the deployments in terms of those (though it requires the new annotation-based imagestream references feature, since they are not DCs), but i don't really see what it buys us. We still need to pick a tag in the imagestream.

[jorgemoralespou]

It buys us that we can tag in out Imagestream the images as we want, hence avoiding the external image progression.

we can have openshift/k8s-service-catalog-apiserver:v3.6.0-rc.0 referencing quay.io/kubernetes-service-catalog/apiserver:canary or any other image. They can push any update to the tag and we would prevent origin to fetch a different image by not having the image stream pull-through configured. The image referenced in our Imagestream, which should be tested, will always be the image we fetch, no matter what changes to that external image and tag happen.

This adds a little boilerplate to release management, but I think it's one of the reasons we created Imagestreams for.

Other option, could be to mirror that image in dockerhub under one namespace we control, but that would prevent ease of development, I think.

[bparees]

@jorgemoralespou i think the scenario you're talking about sounds more like what OCP should do when deploying the SC, but not necessarily what oc cluster up needs to do right now. (It would be nice for oc cluster up to adopt whatever OCP does to deploy the SC in the future, unfortunately we had to blaze the trail within oc cluster up so we didn't have that option).

The image referenced in our Imagestream, which should be tested, will always be the image we fetch, no matter what changes to that external image and tag happen.

We're still going to pick up the latest version of the image tag on initial import, even with an iimagestream, so i'm not sure what you're saying here. Either we have a tag we can trust, or we don't. If we don't, we're potentially going to get broken no matter what we do unless we hardcode a sha reference.

Furthermore, the SC template is set to "pullifnotpresent", so if you have a particular SC image you want to use, you can pull it yourself and tag it as :canary locally. (And once you've pulled it once, it's never going to get replaced with something new/broken unless you remove that image or explicitly pull a new image).

So again, my main concern here is that the SC team provide us with a tag that we can make some compatibility guarantees around. Without that, the rest of this discussion is moot.

[jorgemoralespou]

@bparees of course if we can control how those images are tagged, that is a better option, but if not, as you say an imagestream with a tag to the sha256 of the image would guarantee that the remote image that is tested is the one shipped. Even with pullifnotpresent strategy this would work.