Description of problem: apps/v1beta* APIs will be dropped in 4.4, all the examples have to be migrated to use apps/v1 (same goes for extensions) Version-Release number of selected component (if applicable): oc version Client Version: version.Info{Major:"", Minor:"", GitVersion:"v4.2.0-alpha.0-56-ge6a379d", GitCommit:"e6a379d50", GitTreeState:"clean", BuildDate:"2019-09-05T10:19:53Z", GoVersion:"go1.13", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0+d4cacc0", GitCommit:"d4cacc0", GitTreeState:"clean", BuildDate:"2019-05-02T11:52:09Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"} (watch for selectors - there were changes about some fields being required - try to create the modified resource to be sure)
Based on my scans, cluster-samples-operator only has refs to apps/v1beta* in its vendor tree. So this may be a case of bumping deps accordingly. The CRD def in our manifests dir uses apiextensions.k8s.io/v1beta1 Assuming that does not fall under the apps/v1beta* category.
Samples operator owns the example apps, right? So something like https://github.com/openshift/library/pull/193 (+ fixing selectors if needed) > apiextensions.k8s.io/v1beta1 That is a different api group (not related). This applies only to apps/v1beta* and extensions/v1beta1 per https://github.com/kubernetes/kubernetes/pull/70672/commits/24f04b32c225b5a13808c64d24662dfac370595b
(In reply to Tomáš Nožička from comment #2) > Samples operator owns the example apps, right? So something like Yes and no. Sample operator owns the installation, but not the definition. As Adam mentioned in your openshift/library PR, the various content providers technically own that. So technically, opening various github/jira/bugzilla items for each of them would be the process here. But yes, that is relatively speaking logistically much more onerous to track and drive to completion. We should probably do that regardless, but perhaps not fully depend on that. On the openshift side, I could see two possible approaches: 1) update the openshift/library import logic that Corey wrote to auto-correct any incoming templates while the content providers schedule their updates. Rather than update the content directly like you did in your openshift/library PR, we would update https://github.com/openshift/library/blob/master/import_content.py 2) yes, update the samples operator to do that auto correction just prior to creating the templates. Either way, feels more like a Jira than a bugzilla. Ben/Adam/Corey - thougts on either the tracking or workaround aspects I've just noted? > https://github.com/openshift/library/pull/193 (+ fixing selectors if needed) > > > apiextensions.k8s.io/v1beta1 > > That is a different api group (not related). This applies only to > apps/v1beta* and extensions/v1beta1 per > https://github.com/kubernetes/kubernetes/pull/70672/commits/ > 24f04b32c225b5a13808c64d24662dfac370595b yep what I suspected but thanks for clarifying.
> Ben/Adam/Corey - thougts on either the tracking or workaround aspects I've just noted? fyi this blocks addition of the alert that must land for 4.3 release - BZ seems like the only channel to guarantee landing for the release. Examples using deprecated and already removed API by upstream sounds like a bug. also e2e will fail if the alert is firing - so we can't merge it until it is fixed. https://github.com/openshift/cluster-kube-apiserver-operator/pull/625 > Sample operator owns the installation, but not the definition. yeah, I am not sure if there are more specific BZ components for each of these examples, feel free to delegate or reassign > 1) update the openshift/library import logic that Corey wrote to auto-correct any incoming templates while the content providers schedule their updates. Rather than update the content directly like you did in your openshift/library PR, we would update https://github.com/openshift/library/blob/master/import_content.py IMO this shouldn't be auto-synced in PR validation so we can fix stuff there without being blocked waiting on upstream changes. Should be more like vendoring flow where you sync on your request and can patch it afterwards if need be.
So Tomas's warning about the selectors proved true. Taking the cache-service template for example, in addition to changing apiVersion to apps/v1, I had to add selector: matchLabels: application: ${APPLICATION_NAME} template: metadata: labels: application: ${APPLICATION_NAME} to the StatefulSet.spec in order to get a template instantiation to work. The resulting pod logs look OK, but at this point, and thinking about it a bit more, some sort of validation of the specific datagrid function seems warranted for such a change. I.E. testing by the datagrid folks on top of openshift. And beyond the scope of testing we would as our QE to do. Going with those premises, I think at this point, if we want to unblock https://github.com/openshift/cluster-kube-apiserver-operator/pull/625, we simply change samples operator to not install templates with apps/v1beta1 content, and inform the affected folks. If https://github.com/openshift/library/pull/193 is correct, it is only the infinispan/datagrid folks. Though certainly I can add logging in samples operator to confirm who is excluded. @Ben - thoughts?
if it's really only infinispan templates that are at issue here i'd say just patch it in samples operator and notify them to fix their template upstream (or even submit the PR yourself since we know the repo it comes from)
My preference is to open PRs upstream and ping the owners - let them know this is urgent and their templates will break on 4.3. If we don't get approvals soon (ex 10/25) then we should pursue patching the samples operator to not install the template (and log a warning).
I can see the pros/cons with either approach, but in the end, manually patching the json in the samples operator payload avoids any runtime code changes, so I'm going to manage that way. I'll get the PR up, but mark it hold initially, to see if I can get upstream PRs I create merged, etc.
@XiuJuan for verification, I'm good with you just running `oc get template cache-service -n openshift -o yaml` and `oc get template datagrid-service -n openshift -o yaml` and making sure the StatefulSet objects are not v1beta1
$ oc rsh cluster-samples-operator-6f4d89476c-k7m6c sh-4.2$ cd /opt/openshift/operator/ocp-x86_64/ sh-4.2$ grep -i 'v1beta1' -rn --color ./* sh-4.2$ exit $oc new-app cache-service -n xiu12 -p APPLICATION_USER=xiutest $oc new-app datagrid-service -n xiu12 -p APPLICATION_USER=xiutest $oc get StatefulSet -n xiu12 -o yaml | grep v1beta1 $ Don't find v1beta1 apis in 4.3 4.3.0-0.nightly-2019-11-02-092336 samples operator.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0062