Origin: `oc get dc` deprecated?

[lomholdt]

In older versions of the CLI (oc v3.6.173.0.83) i could do a oc get dc where the dc was a shorthand for deploymentconfig. But in the newest version oc v3.9.0+191fece it gives an error the server doesn't have a resource type "dc".

Version

oc v3.9.0+191fece

Steps To Reproduce

1. oc get dc

Current Result

the server doesn't have a resource type "dc"

Expected Result

A list of deploymentconfigs

Additional Information

[mfojtik]

I can't reproduce this in 3.9 cluster using 3.9 oc binary.

[soltysh]

@lomholdt can you include oc get dc --loglevel=9 here?

[lomholdt]

Hm, the output is full of my auth Bearer tokens, I will have to clean it first.

[lomholdt]

I am however running on:
oc v3.9.0+191fece
kubernetes v1.9.1+a0ce1bc657
features: Basic-Auth

Server https://myopenshiftplatform
openshift v3.6.173.0.113
kubernetes v1.6.1+5115d708d7

[soltysh]

The fact you're running new client against old server might be the problem. In newer versions we rely on the server to provide the information about aliases, such as ds, whereas previously these were hardcoded. By definition we only provide +/-1 version compatibility, so I'd suggest running 3.6 client against 3.6 cluster.

[lomholdt]

Ah, I understand. That makes total sense. Thank you @soltysh and @mfojtik.

Thanks!

[gunjansharma18]

Thanks but I dont see any reason why we should rely on server to get the information and support only with +/-1 version @soltysh. Is this is a bug which will be fixed ?

[soltysh]

Is this is a bug which will be fixed ?

Nope, it works just like it was expected, including +/- 1 version compatibility

[bd12]

sorry for opening this up again, but I'd like to share that I also faced the error with newer versions. Accessing (oc get dc) a v3.11 cluster with a v3.9 client failed as reported. Running the same command with a v3.11 client does return the expected list of deployment configs.

[gitkent]

Hi, we got error message completely unrelated to oc client/server version mismatch:

oc policy add-role-to-user view system:serviceaccount:mynamespace:mysa -n mynamespace
Error from server (Forbidden): policybindings ":default" is forbidden: User "myuser" cannot get policybindings in the namespace "mynamespace": User "myuser" cannot get policybindings in project "mynamespace"

OC client - v3.5
Openshift - v3.10

We can't reproduce this after upgraded OC Client to v3.10

[soltysh]

OC client - v3.5
Openshift - v3.10

We don't support that big version skew between client and server, only +/- 1.

[jballurr]

Having this issue with +/- 1 skew

$oc version
oc v3.10.89
kubernetes v1.10.0+b81c8f8

Server <>
openshift v3.11.104
kubernetes v1.11.0+d4cacc0

oc get dc
error: the server doesn't have a resource type "dc"

Is this a bug ?

[gerardorosiles]

Same issue here when doing
oc get dc/myapp.
the server doesn't have a resource type "dc"
This command was working as of last week with major versions being the same. I don't know if there was a minor version upgrade performed by cluster administrator. I can do oc get displayConfig and things work.

I am using
oc v3.9.0+191fece
kubernetes v1.9.1+a0ce1bc657
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://ocp-master.esl.saic.com:8443
openshift v3.11.43
kubernetes v1.11.0+d4cacc0

[mirekphd]

The fact you're running new client against old server might be the problem. In newer versions we rely on the server to provide the information about aliases, such as ds, whereas previously these were hardcoded. By definition we only provide +/-1 version compatibility, so I'd suggest running 3.6 client against 3.6 cluster.

This intolerance to API server vs CLI version differences applies also to older client vs. newer server situations. And even if there is just 1 minor version difference (like 3.10 client against 3.11 server in our case). It afffects not only dc, but also bc, and is objects. The problem has appeared suddenly after two years of this combination working absolutely fine. The solution was to upgrade the client to the same minor version as the API server.