Create targetNamespace if it does not exist

[zimme]

Helm v2 defaults to creating the namespace if it doesn't exist when installing a chart.

Helm v3 on the other hand does not do this as it's seems to be praxis in the k8s eco system not to error out on missing namespace. However It seems as though helm v3 added a --create-namespace flag that could be used to create the namespace. It's available since 3.2.0 if I understood it correctly.

Would you accept a PR that uses that flag as the default?

[mkoperator]

There is a limitation in the default create-namespace functionality I outlined in the rfe here: helm/helm#8570
That makes it less useful for Rancher backed clusters. tl;dr; no annotations and labels support.

We could also add a wrapper on our side when a helm create-namespace is defined in the spec to optionally include annotations and labels and trigger the namespace creation before executing the helm release.

[fredleger]

i would suggest implementing in two steps:

• supports --create-namespace = true
• later support annotations

As i see it it can still be useful for us without labels or annotation.
The use case was to boostrap a cluster without any access yet. A pitty to see it failing because of missing ns (i can still add it to the manifests right, but why ?)

[jasine]

any progress?

[riuvshyn]

any updates on this?

[sergey-kudriavtsev]

Maybe something is already born?

[gioppoluca]

any update? this is needed!

[gioppoluca]

to better explain the need:

• this tool is used by rancher in installing RKE2 on custom clusters
• the cilium CNI has options for installing ServiceMonitor CR for Hubble (for example)
• this requires to have the monitoring ServiceMonitor CR and calls for installing the HelmChart from the rancher chart repo for example
• this chart wants to activate a job in the cattle-monitoring-system AND all will break since the targetNamespace is not there so the result will be:

1. monitoring CRD not installed
2. cilium not installed
3. cluster not installed

Thus please add this options quick

[brandond]

We prefer to leave the target namespace creation to the user, as there are issues if it is managed by helm - as discussed above. If you're using a manifest with a HelmChart resource in it, it is quite easy to ensure that the manifest also includes the namespace.

this chart wants to activate a job in the cattle-monitoring-system AND all will break since the targetNamespace is not there

Which chart are you talking about? If you're using a Rancher chart, management of required namespaces should be managed by Rancher itself.

[gioppoluca]

Really have difficulty in understanding why ... this is a pain in the gitops operations.
So if I want to create a cluster that deploy also the monitoring CRD to allow cilium to be properly configured I will have to prepare a chart with only the namespace creation add it to the "additionalManifest" again with the bootalbe = true to workaround this strange behaviour.
Strange to have to implement all these things; the expectation is that it should work out of the box.
Fleet behave like this: if there is not the namespace it creates it (apart its own quirks on updates).

I'm using rancher-monitoring-crd chart and it does not manage any namespace creation and BTW in a chart that should install CRDs I would not expect that it even needs a namespace at all, but having looked into it it makes use of a Job that obviously needs a namespace to work.
As said the need is to have CRDs during cluster creation so in boostrap of the cluster or cilium will NOT install due to dependencies.
Will go for the workaround but is a pity that there is no simpler and more direct option like having the helm controller managing the "kustomization" of the namespace addition (I understand that missing labels or annotations could be a problem for rancher but how fleet solves that? Could that be an inspiration?).

Also this is something that on the Rancher side should be documented a bit more also with these namespace details since is part of the RKE2 deployment.

[brandond]

You still haven't mentioned which chart you're referring to. I assume you're talking about the Rancher Monitoring charts? Those are designed to be deployed by Rancher itself, not directly via additionalManifest on the downstream cluster, which is why it expects that the cattle-monitoring-system NS has already been created by Rancher.

[gioppoluca]

Yes as I wrote we use rancher-monitoring-crd from https://charts.rancher.io.

The thing you say is most strange and utterly new since we discussed monitoring deployment with rancher support and this never came out.
Also this is from fleet examples:
https://github.com/rancher/fleet-examples/blob/master/single-cluster/helm-multi-chart/rancher-monitoring/fleet.yaml

What differs from an operation done by fleet and one done by the additionaManifest? A chart is a chart, the operation behind it is a helm operation.
I think that if charts from https://charts.rancher.io are not meant to be used through fleet it should be stated clearly. But Rancher should also document how to automatically set a cluster with those charts since we need to find the UI integrations and are not happy of having to deploy the prometheus operator as it is.

[brandond]

Fleet and the very basic Helm controller that is built in to K3s/RKE2 (this project) function very differently. Rancher expects that charts in the catalog are going to be deployed by Fleet. If you're going to use Rancher, you should deploy Rancher's things the Rancher way, which means using Fleet and not this Helm controller.

I'm a K3s/RKE2 dev; I've pinged some folks internally to see if they can suggest a way to get Rancher's charts installed using Fleet without having to use the UI.