Chart with fixed namespace brakes Helm convention about operator HOT 5 CLOSED

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).

from operator.

@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).

from operator.

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.

from operator.

@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.

from operator.

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

from operator.