ResourceNotUniqueError on resources.get(api_version='v1', kind='DeploymentConfig')

[FlorianFusseder]

If i want to create a simple get with:
dyn_client.resources.get(api_version='v1', kind='DeploymentConfig')
for a DeploymentConfig, ill get the following exception:

File "C:\Projekte\openshift-scripts\venv\lib\site-packages\openshift\dynamic\client.py", line 639, in get raise ResourceNotUniqueError('Multiple matches found for {}: {}'.format(kwargs, results)) openshift.dynamic.exceptions.ResourceNotUniqueError: Multiple matches found for {'api_version': 'v1', 'kind': 'DeploymentConfig'}: [<Resource(v1/deploymentconfigs)>, <Resource(v1/generatedeploymentconfigs)>]

Shouldn't this be unique? It is a standard resource? How to i get the resource <Resource(v1/deploymentconfigs)>?

[willthames]

This is very similar to ansible/ansible#55221

Only seems to be a problem for very old openshifts (3.6 or older), there is a workaround in the above issue.

@fabianvf do you any more thoughts on this one?

[cben]

There is also a similar collision between /templates and /processedtemplates, that still exists in openshift (3.11 and 4.1.0-rc.3): openshift/origin#21668.
Can you check if you see similar issue with that?

FWIW in kubeclient (a ruby lib that's also a dynamic discovery-driven client),
I had similar issues: ManageIQ/kubeclient#376 (comment)
and ended up simply blacklisting processedtemplates: ManageIQ/kubeclient#378
Unless you do want oc process like functionality too? In kubeclient we had a special method to do it (ManageIQ/kubeclient#183).

I'm not sure what generatedeploymentconfigs did in the past but I suspect it was a similar POST-only arrangement to processedtemplates? Or maybe it did nothing — 3.6.0 discovery says "verbs": []? 🤷‍♂️
I didn't blacklist generatedeploymentconfigs because in kubeclient it didn't collide due to technicality in method names, but I think you can safely blacklist it too in openshift-restclient-python.

• There is also ReplicationControllerDummy for extensions/v1beta1/replicationcontrollers but that's separate api group, not same kind of collision, silly but harmless 😸?

P.S. https://github.com/cben/kubernetes-discovery-samples may come in handy for checking what discovery info looks like in different versions.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci-robot]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.