Bug 1764219 - migrate examples from apps/v1beta* APIs to apps/v1
Summary: migrate examples from apps/v1beta* APIs to apps/v1
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Samples
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: 4.3.0
Assignee: Gabe Montero
QA Contact: XiuJuan Wang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-22 13:37 UTC by Tomáš Nožička
Modified: 2020-01-23 11:09 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-23 11:08:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift cluster-samples-operator pull 190 0 'None' closed Bug 1764219: Conv v1beta1 v1 2020-04-30 06:36:28 UTC
Red Hat Product Errata RHBA-2020:0062 0 None None None 2020-01-23 11:09:20 UTC

Description Tomáš Nožička 2019-10-22 13:37:40 UTC
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)

Comment 1 Gabe Montero 2019-10-22 14:46:54 UTC
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.

Comment 2 Tomáš Nožička 2019-10-23 05:53:18 UTC
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

Comment 3 Gabe Montero 2019-10-23 13:36:11 UTC
(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.

Comment 4 Tomáš Nožička 2019-10-23 13:58:03 UTC
> 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.

Comment 5 Gabe Montero 2019-10-23 15:35:37 UTC
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?

Comment 6 Ben Parees 2019-10-23 15:55:15 UTC
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)

Comment 7 Adam Kaplan 2019-10-23 16:15:50 UTC
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).

Comment 8 Gabe Montero 2019-10-23 18:05:43 UTC
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.

Comment 10 Gabe Montero 2019-10-31 17:51:19 UTC
@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

Comment 11 XiuJuan Wang 2019-11-04 09:31:22 UTC
$ 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.

Comment 13 errata-xmlrpc 2020-01-23 11:08:59 UTC
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


Note You need to log in before you can comment on or make changes to this bug.