Chart with fixed namespace brakes Helm convention

[davivcgarcia]

Expected Behavior

When installing the Helm Chart, the user expects that namespace is configurable by flag --namespace. However the current version fixes namespace and doesn't respect the convention.

https://helm.sh/docs/faq/changes_since_helm2/#release-names-are-now-scoped-to-the-namespace

Current Behavior

If you render the current chart version, you'll see that many resources are created with hard-coded namespace tigera-operator.

helm template calico projectcalico/tigera-operator --namespace dummy

Possible Solution

Update the Helm Chart to respect the namespace definition provided by the user when supplied --namespace, and recommend the usage of tigera-operator in the docs. Also, drop the creation of the namespace and recommend the usage of the flag --create-namespace instead.

Context

The way the chart is written today is breaking the GitOps workflow using FluxCD.

[stevehipwell]

@davivcgarcia see #1427 for a discussion on this behaviour.

The latest version of my tigera-operator chart should support being installed into any namespace as well as setting other standard values that are missing from the official chart (FYI there is currently no OpenShift support).

[tmjd]

This isn't really the correct repo to be discussing the helm chart, it isn't generated from here or available from here. I'd suggest creating an issue in github.com/projectcalico/calico as that is the source of the helm chart.

That being said, what is helm's take on charts that should have a single deployment in a cluster? In the helm docs you linked to it is referring to deploying multiple of the same chart which does not make sense with Calico. It seems better to me that it should be hard coded so there is no chance of deploying multiple of the chart, or maybe there is a better way to enforce that with helm charts.

[stevehipwell]

@tmjd blocking multiple installs isn't a Helm concern or feature, but I suspect that it could be achieved without needing to hardcode the operator namespace by installing an object into the kube-system namespace that couldn't be "adopted" by further attempted installations. Off the top of my head a configmap with a fixed name being installed into kube-system with the release namespace as a label would block additional installs.

[davivcgarcia]

This isn't really the correct repo to be discussing the helm chart, it isn't generated from here or available from here. I'd suggest creating an issue in github.com/projectcalico/calico as that is the source of the helm chart.

Sorry about that. I raised the issue here because the Helm Chart is about the tigera-operator and I didn't find any other repository dedicated to it.

That being said, what is helm's take on charts that should have a single deployment in a cluster? In the helm docs you linked to it is referring to deploying multiple of the same chart which does not make sense with Calico. It seems better to me that it should be hard coded so there is no chance of deploying multiple of the chart, or maybe there is a better way to enforce that with helm charts.

I agree with @stevehipwell, where Helm is not focused on ensuring singleton. There are many other Helm Charts out there with the same requirement but without hard-coding namespace into the templates (AWS Load Balancer Controller, Metrics-Server, Custer Auto-Scaler, etc).

[davivcgarcia]

I'm closing this issue and opened a new on the the repository referred by @tmjd. Thanks!