helm: Helm should not ignore namespace passed on command line

I have the prometheus operator running in my cluster. I want to test a new version of the prometheus operator by running it in a separate namespace. I used the “–namespace” option with the existing release name. Instead of deploying into the namespace that I specified with the “–namespace” option, it prints a warning and deploys into the original namespace.

helm upgrade --install --namespace jko-test prometheus-operator helm-charts/prometheus-operator-0.22.0
WARNING: Namespace "jko-test" doesn't match with previous. Release will be deployed to monitoring
Release "prometheus-operator" has been upgraded. Happy Helming!

While I understand the motivation to use the original namespace I think it’s the wrong thing to do here. If the user specifically asks for a namespace and it doesn’t match the original helm should exit with an error.

Output of helm version:

$ helm version
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Output of kubectl version:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.2", GitCommit:"81753b10df112992bf51bbc2c2f85208aad78335", GitTreeState:"clean", BuildDate:"2018-04-27T09:22:21Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.4-2+4551f1c28fa6c7", GitCommit:"4551f1c28fa6c7a06ae19701bb14a3a8eacf0caf", GitTreeState:"clean", BuildDate:"2018-03-13T14:25:14Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 10
  • Comments: 18 (9 by maintainers)

Commits related to this issue

Most upvoted comments

This is a case where avoiding user errors should trump backwards compatibility.

helm upgrade --install nginx --namespace debug should never interfere with the nginx intallation in namespace production.

It’s not well known how helm behaves in this situation, but it’s totally justified for a user to expect a release in a different namespace to be left alone. Here is how the story unfolds: The user intends to perform an action in good faith. Helm detects a conflict between user intent and the action it’ll undertake. It informs the user of said conflict continues to perform the dangerous thing anyway. Imagine what you’d do if your colleague behaved that way.

workaround: running helm del <release-name> is not enough you need: helm del --purge <releasename> after that the warning won’t show and it will deploy to the specified name space

@michelleN it was done with a warning message because of backwards compatibility reasons.