Odd namespace behaviour incluster for kubectl deploy about devspace HOT 4 OPEN

@kuuji Thanks for submitting this issue! Yes this does seem odd, and the recommended usage is to use devspace use namespace [NAMESPACE] before running devspace deploy. This results in updating the your kube config to have a namespace set as well, which is more reliable for advanced uses of DevSpace, where other processes that use the kube config are involved.

I'll bring this up for discussion to see if we either want to fix this for the simpler cases, or officially deprecate the flag in favor of devspace use namespace

from devspace.

@kuuji Thanks for submitting this issue! Yes this does seem odd, and the recommended usage is to use devspace use namespace [NAMESPACE] before running devspace deploy. This results in updating the your kube config to have a namespace set as well, which is more reliable for advanced uses of DevSpace, where other processes that use the kube config are involved.

I'll bring this up for discussion to see if we either want to fix this for the simpler cases, or officially deprecate the flag in favor of devspace use namespace

@lizardruss I cannot use devspace use namespace while running incluster. There is no kubeconfig when incluster, it's using the service account and the default namespace becomes the namespace the pod is in. So sadly this isn't an option.

I don't think the flag should be deprecated if there is no other way for incluster.

edit: I did try that as well ;)

from devspace.

@kuuji Ah I see, I skimmed over the incluster part. I'm surprised that setting the namespace in the deployment config didn't work. We'll take a look, but it may be some time before this gets prioritized.

from devspace.

@lizardruss I found a bit of time to dig and got to the bottom of it. I'll put up a fix today or tomorrow.

the TLDR; is it's because of the way the manifests are rendered in https://github.com/devspace-sh/devspace/blob/main/pkg/devspace/deploy/deployer/kubectl/builder.go#L111-L166 when incluster. This is specifically because we run kubectl to render the manifests and when you're incluster kubectl will add the namespace you're in to all the manifests.

This doesn't affect inlineManifests, because we don't use kubectl to render that.
And this doesn't affect when you're not incluster because the namespace kubectl inject will be based on what's in your kubeconfig.

from devspace.