hashicorp / waypoint

A tool to build, deploy, and release any application on any platform.
https://waypointproject.io
Other
4.76k stars 327 forks source link

[plugin/helm] deployment does not respect namespace parameter #3065

Open rhabbachi opened 2 years ago

rhabbachi commented 2 years ago

Describe the bug When using the helm plugin to deploy a helm chart, setting the namespace (optional) parameter is not reflected on the deployment. The chart is deployed to the "default" namespace.

Steps to Reproduce Example waypoint.hcl snippet

app "opensearch" {
  build {
    use "docker-pull" {
      image = "opensearchproject/opensearch"
      tag   = "1.2.4"
    }
    }
  }

  deploy {
    use "helm" {
      namespace  = "opensearch"
      name       = "opensearch-${workspace.name}"
      repository = "https://opensearch-project.github.io/helm-charts/"
      chart      = "opensearch"
      version    = "1.8.2"
    }
  }
}

Steps to reproduce the behavior.

Please include any waypoint.hcl files if applicable, as well as a GitHub Gist of any relevant logs or steps to reproduce the bug. Running waypoint commands with -v up to -vvv will include any additional debugging info in the log.

Expected behavior Helm chart deployed to the specified namespace.

Waypoint Platform Versions

Additional context

evanphx commented 2 years ago

Thanks for the report! I'm guessing the value just isn't being passed through correctly, we'll take a look!

dzirg44 commented 2 years ago

Faced with the same issue (

yellowmegaman commented 2 years ago

Same here, specified namespace is created, but resources are in the namespace "default"

tusharRepo commented 2 years ago

I am facing the same issue, can someone please look into this.

briancain commented 2 years ago

Hey all - as far as I can tell looking at the helm plugin code it looks like the Helm deploy plugin is properly setting namespace using either the install or upgrade client.

This is where we take in the namespace param from the config and set it on our helm client https://github.com/hashicorp/waypoint/blob/1a48c27c4b9dabc9bc779cf4a3179b1cafb7ed08/builtin/k8s/helm/platform.go#L92-L99

This is where we set it for new releases: https://github.com/hashicorp/waypoint/blob/1a48c27c4b9dabc9bc779cf4a3179b1cafb7ed08/builtin/k8s/helm/platform.go#L118

And we set it for helm upgrades too: https://github.com/hashicorp/waypoint/blob/1a48c27c4b9dabc9bc779cf4a3179b1cafb7ed08/builtin/k8s/helm/platform.go#L154

For those that are experiencing issues with the Helm plugin not deploying to the proper namespace, could you please provide the waypoint.hcl you are using, as well as logs from the runner that deployed the application with the helm plugin (either from running waypoint up -vvv or the debug logs from a remote on-demand runner if that's your setup). Thank you!

rhabbachi commented 2 years ago

@briancain My setup is waypoint using local runner and local kubernetes context. This is a pseudo config similar to what I use

project = "keycloak"

variable "k8s_context" {
  type = string
  # This is a dummy value to make `waypoint config sync` work.
  default = "stage-eks"
}

variable "k8s_namespace" {
  type    = string
  default = "keycloak"
}

app "keycloak" {
  url {
    auto_hostname = false
  }

  # Build specifies how an application should be deployed. In this case,
  # we'll build using a Dockerfile and keeping it in a local registry.
  build {
    use "docker-pull" {
      image = "bitnami/keycloak"
      tag   = "18.0.2-debian-11-r19"
    }
  }

  deploy {
    use "helm" {
      context   = var.k8s_context
      namespace = var.k8s_namespace

      name       = "keycloak-${workspace.name}"
      repository = "https://charts.bitnami.com/bitnami"
      chart      = "keycloak"
    }
  }
}

Waypoint command:

waypoint up -w pr-3065 \
  -var='k8s_context=infrastructure-stage' -var='k8s_namespace=keycloak'

The thing is, the helm chart seems to be deployed to the "default" namespace, but reports itself as deployed to the "keycloak" namespace.

❯ helm -n default list
NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
keycloak-develop        default         8               2022-07-26 11:47:37.427337705 +0100 CET deployed        keycloak-0.1.0  17.0.0
keycloak-master         keycloak        1               2022-08-10 11:02:43.898414315 +0100 CET failed          keycloak-0.1.0  17.0.0
keycloak-pr-3065        keycloak        1               2022-08-10 11:22:39.772550715 +0100 CET deployed        keycloak-9.6.8  18.0.2
❯ helm -n keycloak list
NAME    NAMESPACE       REVISION        UPDATED STATUS  CHART   APP VERSION

But the pods and other resources seems to be deployed to the correct namespace:

❯ kubectl get pods -n keycloak
NAME                            READY   STATUS                       RESTARTS   AGE
keycloak-master-postgresql-0    0/1     CreateContainerConfigError   0          45m
keycloak-pr-3065-0              1/1     Running                      0          25m
keycloak-pr-3065-postgresql-0   1/1     Running                      0          25m

Hence the confusion, deploying charts manually or via terraform does not have this behavior.

rhabbachi commented 2 years ago

~Adding a quick note, deploying with the helm plugin seems to not set the {{ .Release.Namespace }} variable which causes sub charts that sets the namespace metadata (like this one ) to be dumped to the default namespace.~ Wrong observation. {{ .Release.Namespace }} with waypoint seems to be working as it should.

demophoon commented 2 years ago

Hello all,

@HenryEstberg and I have been able to reproduce this issue, there is definitely a configuration we are missing when piping the namespace through to Helm properly. We still suspect that something is missing in how we setup Helm's config initially within the plugin.

Walking through the code we setup helm's configuration for running actions before we have even determined which namespace the application should be deployed into. Passing that namespace through to actionInit to then use for initializing helm's action results in the application being deployed to the default namespace and the helm resources being created in the given namespace.

https://github.com/hashicorp/waypoint/blob/cde24a70a257127185be1c4d0daeb86f90cd7f43/builtin/k8s/helm/api.go#L42-L48

We also looked to see how the default namespace was determined within /builtin/k8s/api.go to see if there was a proper way to set the namespace within the kubeconfig in the restClientGetter struct we pass to helm to instead not inherit the configured default namespace and instead the one which we desire.

We have not found a way yet and need to do further investigation to determine what the differences are between the way helm is setup within the plugin and other areas of Waypoint which also use Helm. Namely during the installation of Waypoint server and runners.