ResourceNotUniqueError on resources.get(api_version='v1', kind='DeploymentConfig')
FlorianFusseder opened this issue · 6 comments
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)>?
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?
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
ReplicationControllerDummyfor 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.
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
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
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-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.