search

crossplane-contrib / provider-argocd

Crossplane provider to provision and manage Argo CD objects
Apache License 2.0
68 stars 35 forks source link

ProviderConfig: Reference a serverAddress #123

Closed maximilianbraun closed 7 months ago

maximilianbraun commented 8 months ago

What problem are you facing?

Today, the provider retrieves its argocd server address via a field in the ProviderConfig. In our environments the server address is stored in configmaps or secrets.

How could provider-argocd help solve your problem?

While it is a viable option to create a XR(D) for that, i feel like it would be great addition to the provider to read that field from another source, like a secret or a configmap.

For implementation purposes, I'd restrict it to secrets, since most of that is already part of the crossplane SDK. One could even think about to use a CommonCredentialSelector (maybe not), or a SecretKeySelector (maybe better).

maximilianbraun commented 8 months ago

I did a Poc implementation in this branch here https://github.com/crossplane-contrib/provider-argocd/compare/main...maximilianbraun:provider-argocd:feat/serverFromCredsSource

MisterMX commented 7 months ago

I am unsure about this change as it would make the provider config much more complicated. Is it possible for you to directly create (or patch) the provider config from your source system?

maximilianbraun commented 7 months ago

Hey @MisterMX!

Thanks for the feedback.

We often times have the case, that data like endpoints and secrets come from some external management system which pushes them to the clusters in form of ConfigMaps and Secrets. I understand your concern, this is why the poc implementation makes this completely optional for the user to use.

Yes it generally would be possible to wrap that and pipe the data via some mechanism into it. All of this comes with a layer of indirection and for the provider configs I tend to hold it simple and understandable.

An alternative solution which would also be in my favour is to make the serverAddress field optional, but read the server address from the provided credential. Could you imagine this?

MisterMX commented 7 months ago

I understand. However, I would like to avoid fragmentation by having single secret refs for every field in a PC spec. Now we would only apply it to serverAddress but I can image folks also want to have plainText to configured from a secret.

I wonder if it is a good idea to reference a config JSON within a secret that can contain all possible fields?