https://pulumi.com logo
#general
Title
# general
g

glamorous-printer-66548

05/29/2019, 10:33 PM
Did something recently changed with regards to precedence rules of provider attributes in the kubernetes (typescript) provider? I recently upgraded to
@pulumi/kubernetes: 0.23.1
and seeing some odd behaviour: We instantiate provider instances dynamically via
new gcp.Provider({kubeconfig: ..., namespace: 'namespace-A'})
and then use this provider instance in some resources like
new k8s.core.v1.ServiceAccount(foo, {metadata: {namespace: 'namespace-B'}}, {provider: k8sProvider})
. I would expect the serviceaccount to be created in
namespace-B
in the example above, but it actually gets created in
namespace-A
. I can create a more detailed repro if necessary but wanted to ask first if this intentional or a known issue? @creamy-potato-29402?
w

white-balloon-205

05/29/2019, 10:35 PM
If I recall correctly the
namespace
property on
Provider
instances used to be ignored, and was recently changed to actually set a default namespace. That said, I agree it should not override the namespace if provided explicitly on a resource. Could you open an issue? This sounds like a bug to me.
g

glamorous-printer-66548

05/29/2019, 10:35 PM
ok makes sense. Yep, let me open an issue
g

gorgeous-egg-16927

05/30/2019, 2:13 AM
Actually, that is the intended behavior, currently. https://github.com/pulumi/pulumi-kubernetes/pull/538/files#diff-5d82f691515dea3a9f870cf8d1a0fc84R74 https://github.com/pulumi/pulumi-kubernetes/pull/506#issue-265491527 Feel free to open an issue if you disagree with that design, and we can discuss further. If you don’t want the resource to be in that namespace, you can create a new provider that references the same kubeconfig/cluster without the namespace arg set.
g

glamorous-printer-66548

05/30/2019, 9:24 AM