Open gniltaws opened 1 month ago
We solved this easily using helm parameters. You can leave the clusterName
blank in values.yaml
, and in the ApplicationSet, set the helm parameter (i.e., clusterName)
source:
helm:
parameters:
- name: crowdstrikeConfig.clusterName
value: "{{.name}}" # if using a Cluster Generator, it is automatically available.
The usage of helm parameters is generally the appropriate and preferred approach to handling this.
Our clusters are managed by gitops/Argo CD. We have a global variable for the cluster's shortname
.Values.global.clusterName
which I'd like to be able to use, instead of needing a separate Values.yaml for each cluster.I've worked out a few ways of doing it, in separate branches in my fork: (I'm pretty inexperienced with Github.com, so apologies if this is a confusing way to link them)
Values.global.clusterName
This uses my chosen variable, which might not be what others would want to use.This lets the user define a template (which can reference another variable)
This adds a new variable in Values.yaml
.Values.crowdstrikeConfig.existingConfigMap
. When defined,configmap.yaml
is not created andexistingConfigMap
is used in the deployment'senvFrom
:I'd be happy to make any changes needed, but I will need help with the
values.schema.json
validation.