You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand that AWX is open source software provided for free and that I might not receive a timely response.
Feature type
Enhancement to Existing Feature
Feature Summary
I am working with a usecase involving the kubevirt dynamic inventory plugin, which requires Kuberentes credentials be injected into the inventory sync, AWX does not allow the "Openshift/Kubernetes token" default credential type to be attached to inventories. The current workaround is to create a custom credential with the same behavior as the default one, which will be allowed, but feels quite silly.
Select the relevant components
UI
API
Docs
Collection
CLI
Other
Steps to reproduce
Create a SCM based inventory that leveraged an inventory plugin which requires to authenticate to a kubernetes API, ie kubevirt.core
Current results
User is unable to attach k8s token credentials
Sugested feature result
Users will have a consistent experience leveraging this inventory and not have to create a custom credential that is identical in behavior to a preexisting one because they arbitrarily cannot attach the default one to inventories
Additional information
With as many inventory plugins as we see present now, I don't really see a point in limiting what credential types can be attached to scm inventory sources at all.
The text was updated successfully, but these errors were encountered:
Please confirm the following
Feature type
Enhancement to Existing Feature
Feature Summary
I am working with a usecase involving the kubevirt dynamic inventory plugin, which requires Kuberentes credentials be injected into the inventory sync, AWX does not allow the "Openshift/Kubernetes token" default credential type to be attached to inventories. The current workaround is to create a custom credential with the same behavior as the default one, which will be allowed, but feels quite silly.
Select the relevant components
Steps to reproduce
Create a SCM based inventory that leveraged an inventory plugin which requires to authenticate to a kubernetes API, ie kubevirt.core
Current results
User is unable to attach k8s token credentials
Sugested feature result
Users will have a consistent experience leveraging this inventory and not have to create a custom credential that is identical in behavior to a preexisting one because they arbitrarily cannot attach the default one to inventories
Additional information
With as many inventory plugins as we see present now, I don't really see a point in limiting what credential types can be attached to scm inventory sources at all.
The text was updated successfully, but these errors were encountered: