Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1813893 - oc client use apiVersion: extensions/v1beta1
Summary: oc client use apiVersion: extensions/v1beta1
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 4.3.0
Hardware: All
OS: All
unspecified
low
Target Milestone: ---
: ---
Assignee: Maciej Szulik
QA Contact: zhou ying
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-16 12:36 UTC by Robert Bohne
Modified: 2020-03-17 12:21 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-17 12:11:52 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Robert Bohne 2020-03-16 12:36:25 UTC
Description of problem:

OpenShift command line client use apiVersion: extensions/v1beta1, should use apps/v1

Version-Release number of selected component (if applicable):


How reproducible:

$ oc version
Client Version: openshift-clients-4.3.0-201910250623-88-g6a937dfe
Server Version: 4.3.5
Kubernetes Version: v1.16.2

$ oc get deployment/console -n openshift-console -o yaml | grep apiVersion
apiVersion: extensions/v1beta1


Steps to Reproduce:
1. oc get deployment/console -n openshift-console -o yaml | grep apiVersion

Actual results:

apiVersion: extensions/v1beta1

Expected results:

apiVersion: apps/v1


Additional info:

Work-a-round, use deployment.apps:
$ oc get deployment.apps/console -n openshift-console -o yaml | grep apiVersion


The problem with every oc get/edit/.. deployment you hit the alert rule UsingDeprecatedAPIExtensionsV1Beta1

Comment 1 Maciej Szulik 2020-03-17 11:11:12 UTC
oc is getting information which API to use when talking with server from discovery provided from the server.
For backwards compatibility reasons extensions/v1beta1 was set higher than apps thus oc picks that.
It was decided that this is not going to be fixed, which might cause some issues and most importantly
incompatibilities between upstream and openshift. There's a simple workaround available you can use:

oc get|edit... deploy.apps 

which will explicitly use apps/v1, instead.

Comment 2 Robert Bohne 2020-03-17 11:29:29 UTC
That sounds not clear to me. To add some more facts:

- With K8s 1.16 extensions/v1beta1 is deprecated.  (https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) 
- The web ui use apps/v1 and NOT extensions/v1beta1 - that means the user behavior is different between cli and webui.


What is the exact reason for backward compatibility? Do you have an example?


And who is responsible for the default Prometheus alert rule to check for extensions/v1beta1 usage. We should have consistent behavior.  If we use extensions/v1beta1 than in WebUi + CLI + no alert OR we use apps/v1 in WebUI + CLI + alert rule.

Comment 3 Maciej Szulik 2020-03-17 12:11:52 UTC
(In reply to Robert Bohne from comment #2)
> That sounds not clear to me. To add some more facts:
> 
> - With K8s 1.16 extensions/v1beta1 is deprecated. 
> (https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) 
> - The web ui use apps/v1 and NOT extensions/v1beta1 - that means the user
> behavior is different between cli and webui.

webui takes explicit decision which API it uses, cli follows the discovery information,
which allows us to be more dynamic when working with every possible resources, see CRDs, 
for example. It's a concious choice on our side.

> What is the exact reason for backward compatibility? Do you have an example?

This goes back to when extensions/v1beta1 was first introduced, where users
were seeing problems talking with apiserver and getting the right information.
I don't have example of top of my head but I remember there was an issue in kubernetes
repository.

> And who is responsible for the default Prometheus alert rule to check for
> extensions/v1beta1 usage. We should have consistent behavior.  If we use
> extensions/v1beta1 than in WebUi + CLI + no alert OR we use apps/v1 in WebUI
> + CLI + alert rule.

That rule is being removed due to this and other related issues in one of the 
recent upgrades to cluster-kube-apiserver-operator https://github.com/openshift/cluster-kube-apiserver-operator/pull/741

Comment 4 Robert Bohne 2020-03-17 12:21:56 UTC
Thank you for the information, have a nice day.


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