-
Notifications
You must be signed in to change notification settings - Fork 81
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
Allows provider kubernetes to respect connection secret settings #15
Comments
cc @turkenh |
I believe we can just implement the following here: crossplane-contrib/provider-helm#73 |
This is how it looks like at the end: https://github.com/crossplane-contrib/provider-helm/blob/e49c3e791f5c7bd95d50ab0762297daeb084c459/examples/sample/release.yaml#L36 |
That is awesome! It is exactly what we need. Then I think we could add that as a TODO for this provider! |
We're also interested in this feature. @turkenh, I tried your suggestion and replicated what you had done for provider-helm. That seems to work well. If you want to try it out, I pushed a quick-and-dirty, non-tested version of this to Anyway, I wanted to check if you're still open to adding this feature and whether the approach you suggested above still makes sense to you. If so, we would be happy to work on a proper PR for this. |
@st3v yes, feel free to open a PR. Thanks! |
What problem are you facing?
Provider kubernetes is designed to provision and manage Kubernetes objects on (remote) Kubernetes clusters. For a normal Kubernetes object such as a ConfigMap or whatever else, it does not have to define a connection secret, since it does not make sense to use a connection string in order to connect to these Kubernetes objects. For the kubeconfig used to connect to the cluster that these Kubernetes objects reside in, it is handled separately in
ProviderConfig
usingspec. credentials
.However, if the Kubernetes object managed by the provider is something driven by some Kubernetes controller at backend which has more complicated scenario, such as to drive a provisioning of a Kafka instance on the target cluster, then to connect to what is actually provisioned by the Kubernetes object may need some connection string, e.g. the connection string to access the Kafka instance.
Right now, the provider does not write any connection secret by itself. So, if I specify
spec.writeConnectionSecretToRef
, a connection secret with empty data will be created, which is not expected.How could Crossplane help solve your problem?
To allow provider kubernetes to respect the connection settings by creating the corresponding secret would help in this case. Not like other providers, the provider kubernetes itself may not know how to build such connection string, but in case the whatever backend that drives the actual workload provisioning knows that and create the secret, then the provider may have a way that can allows user to specify where to retrieve this string, e.g.: via an optional field called
spec.readConnectionSecretToRef
, then expose it toObject
resource usingspec.writeConnectionSecretToRef
.The text was updated successfully, but these errors were encountered: