Support `valuesTemplatesFrom` in HelmChartProxy, loading values from external resources

[neoaggelos]

User Story

As an operator I would like to specify helm values from external configmap or secret resources, in order to be able to support installing a chart on multiple clusters, with the option to override values on each cluster.

Detailed Description

Currently, HelmChartProxySpec specifies a valuesTemplate field (

cluster-api-addon-provider-helm/api/v1alpha1/helmchartproxy_types.go

Lines 74 to 77 in dad0b2c

	// ValuesTemplate is an inline YAML representing the values for the Helm chart. This YAML supports Go templating to reference
	// fields from each selected workload Cluster and programatically create and set values.
	// +optional
	ValuesTemplate string `json:"valuesTemplate,omitempty"`

). In the scenario where an operator is running clusters for multiple tenants, we would like to have a shared HelmChartProxy object with a list of defaults values, but allow each tenant to override some parts of the values.

To accomodate this, the API could be extended to accept a valuesTemplatesFrom field, with the following spec:

type HelmChartValuesFrom struct {
	// Kind is ConfigMap or Secret.
	//
	// +kubebuilder:validation:Enum:=ConfigMap;Secret
	Kind string `json:"kind"`

	// Name is the name of the ConfigMap resource.
	// It supports Go templating to reference fields from each selected workload Cluster and programatically compute the name of the resource.
	Name string `json:"name"`

	// Namespace is the namespace of the ConfigMap resource.
	// It supports Go templating to reference fields from each selected workload Cluster and programatically compute the namespace of the resource.
	Namespace string `json:"namespace"`

	// Key is the data key to use from the ConfigMap resource.
	// It supports Go templating to reference fields from each selected workload Cluster and programatically compute the data key.
	Key string `json:"key"`

	// Required indicates that the references resource and key must exist, otherwise applying the chart will fail.
	// +optional
	Required bool `json:"required,omitempty"`

	// Priority indicates the priority of this values object. High priority takes precedence. Values from ValuesTemplate will be applied with priority 1, so
	// the default zero value means that values from ValuesTemplatesFrom are applied after.
	// +optional
	Priority int `json:"priority,omitempty"`
}

• required allows ignoring missing keys (e.g. if no overrides are specified, simply ignore)
• priority allows setting priority on the different values templates
• name, namespace and key can also be templated based on the Cluster object. We could include information about the helm release itself.

Anything else you would like to add:

An alternative approach would be to mantain separate almost identical HelmChartProxy objects per application per cluster, but that can quickly become harder to manage.

We would be very interested to implement this feature, we are opening this issue to gather some initial feedback and see if CAAPH finds this interesting or useful to have.

We would also be willing to adjust the scope of this, according to feedback from CAAPH maintainers (e.g. adjusting the supported fields).

/kind feature

[tuxtof]

definitively a good idea, aligned with the way FluxCD is working with valuesFrom

[Jont828]

/triage-accepted

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[tuxtof]

/remove-lifecycle stale