Open rhabbachi opened 2 years ago
Thanks for the report! I'm guessing the value just isn't being passed through correctly, we'll take a look!
Faced with the same issue (
Same here, specified namespace is created, but resources are in the namespace "default"
I am facing the same issue, can someone please look into this.
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!
@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.
~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.
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.
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.
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
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. Runningwaypoint
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