shared responsibility for ccm/csi config

[3deep5me]

Hello,
i currently try to build a home-lab friendly Kubernetes Engine on proxmox - my current task is to integrate this nice ccm/csi. First thanks again for approving and creating the PR for the secret from file.
The originally idea of the PR was to have a "separation of concerns". The engine brings the mandatory/opinionated config like the storageclass name or the needed features, with the secret from file every user can bring there own config without touching the full configuration (hiding complexity). This works for the authentication. Now i stay before the same Issue with the cluster-url. Its highly environment specific but cannot currently decoupled from the more "engine-like" configuration like the features which needs to be enabled. Before starting a PR i would like to discuss if somebody has an idea how to resolve this in a most generic way.
Current PR in the PKE (Proxmox Kubernetes Engine)
https://github.com/Caprox-eu/Proxmox-Kubernetes-Engine/pull/4/files

[3deep5me]

What do you thing of having something like "existingConfigPath" in the helm chart/controller where multiple configuration files can lay - and there will be merged by the application during runtime?
I'm not sure if this is really something common, but at least i know this concept from grafana for adding different dashboards to grafana from different configmaps. (by having all files in one folder)

[3deep5me]

Hello, thank you.
Did I get you right that I can put a list of secrets under existingConfigSecret?

[sergelogvinov]

Unfortunately no, you need to configure the external-secrets to create one config map from many sources.

Or create (find) a new project that merge multiple sources into one - this could be a great new kubernetes related project, as it would help many other projects and GitOps initiatives across the internet.

[3deep5me]

Mhhhh... Not everybody uses external secrets but a new project would be an idea. It would be great if configmaps would just support yaml natively and not via the multi line string, then it would be probably easily manageable with e.g. Kustomize and all other tools.

[sergelogvinov]

Kubernetes secrets and configMaps are simple key-value stores. If we need structured, schema-validated YAML, we should use a CRDs. As far as I know, all CCM/CSI components use config files, so I’d like to follow the same pattern.

[3deep5me]

I fully understand.
What do you thing of having a option inside the ccm called "configPath" or similar? Files in that location could be just merged by the application. But yeah probably i'm the only one who would uses this, but having different config-maps/secrets for different clusters could be maybe really a benefit to structure the config better? (e.g. one ConfigMap for each Proxmox cluster)