The Wayback Machine - https://web.archive.org/web/20210917222848/https://github.com/crossplane/crossplane/issues/2255
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support typed ProviderConfig references #2255

Open
negz opened this issue Apr 9, 2021 · 1 comment
Open

Support typed ProviderConfig references #2255

negz opened this issue Apr 9, 2021 · 1 comment

Comments

@negz
Copy link
Member

@negz negz commented Apr 9, 2021

What problem are you facing?

Currently Crossplane managed resources reference a ProviderConfig by name alone. The key consumer of config is the provider code, where the type (i.e. GVK) of the ProviderConfig is fixed. Other API consumers do not have enough information to resolve an arbitrary managed resources' spec.providerConfigRef to a particular config; for example a web console could not (easily) resolve a providerConfigRef.

In theory a non-provider consumer that knew how Crossplane worked could potentially discover the active ProviderRevision for a particular managed resource (via its CRD) and then figure out which provider configs that revision installed, but doing so is complex and potentially unreliable.

How could Crossplane help solve your problem?

Crossplane could allow managed resources to include an apiVersion and kind under spec.providerConfigRef. Perhaps these fields could be optional (for backward compatibility) but defaulted by the managed resource's CRD schema?

@muvaf
Copy link
Member

@muvaf muvaf commented Apr 9, 2021

Using kubebuilder defaulter marker sounds good and doesn't affect the UX much for human interaction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants