Skaffold: helm: Incorrect namespace selection

[kvokka]

Expected behavior

Skaffold should treat all namespaces separately

Actual behavior

When the service was already deployed to done namespace (call it myns), and I try to deploy the same service to another namespace, for example myns2 it will be deployed again to myns instead of myns2. this makes impossible to deploy the 1 service to 2 different namespaces.

Information

• Skaffold version: version 1.1.0
• Operating system: MacOS 10.15
• Contents of skaffold.yaml:

apiVersion: skaffold/v2alpha1
kind: Config
profiles:
  - name: dependencies
    deploy:
      helm:
        releases:
          - name: memcached
            chartPath: stable/memcached
            remote: true
            valuesFiles:
              - support/skaffold/ondemand/memcached.yaml

UPD: Tried to add namespace option in skaffold.yaml file profiles.0.deploy.helm.releases.0.namespace: myns2. It gives the same bug, as described earlier

Steps to reproduce the behavior

With this I execute

skaffold run -n myns -f skaffold.ondemand.yaml -p dependencies
skaffold run -n myns2 -f skaffold.ondemand.yaml -p dependencies

Having the service running only in myns.

In the output log I see:

Release "memcached" has been upgraded.
LAST DEPLOYED: Mon Jan  6 21:16:15 2020
NAMESPACE: myns
STATUS: DEPLOYED

Tried with Helm 2.16.1 && 3.0.2
Connect https://github.com/helm/helm/issues/2060

[kvokka]

Finally, killed a day i found the workaround for Helm2. Maybe it will be helpful for someone until this fix && Helm3 fix.

# skaffold.yaml

apiVersion: skaffold/v2alpha1
kind: Config
profiles:
  - name: dependencies
    deploy:
      helm:
        releases:
          - name: redis-{{ .NS }}
            chartPath: stable/redis
            remote: true
            valuesFiles:
              - support/skaffold/redis.yaml

export NS=myns && skaffold run -f skaffold.ondemand.yaml -p dependencies -n $NS

[balopat]

Thank you @kvokka for submitting this. Are you using helm 2?
Helm 3 made some improvements around this area: https://helm.sh/docs/faq/#release-names-are-now-scoped-to-the-namespace

With the removal of Tiller, the information about each release had to go somewhere. In Helm 2, this was stored in the same namespace as Tiller. In practice, this meant that once a name was used by a release, no other release could use that same name, even if it was deployed in a different namespace.

However Helm3 has some issues with Skaffold currently :(

Thank you so much for putting the effort in documenting the workaround - this might be the only solution for now for Helm2 users with Skaffold.

[kvokka]

Thank you @balopat

This was tested with Helm 2.16 (but i believe that it should work with the previous versions too) and i do not think, that Helm team will fix this ever.

[foosinn]

As far as i know thats wanted behavior in Helm2. Using the same release name, helm will try to update the existing deployment. I think this issue can be closed.

Release names in Helm2 are global, so you would uninstall the existing app in the other namespace otherwise. Thats why they went with this beavior.

Helm3 uses scoped releases (using secrets local to the namespace), which fixes this issue, but creates others (see #3762)

[tstromberg]

Thank you for the idea!

I'm closing this issue as it's been open a while, and it is not clear if it's still an open issue - particularly with the move to Helm 3. No one has recently stated an interest in addressing this, but if you feel strongly about it, please feel free to add a comment.