Kustomize: Should namePrefix apply to literally declared Namespace?

[bsuh]

kustomization.yaml

namePrefix: hello-

namespace: world

resources:
  - namespace.yaml
  - config.yaml

namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: world

config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: config

~/test % kustomize build .
apiVersion: v1
kind: Namespace
metadata:
  name: hello-world
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: hello-config
  namespace: world

Literal Namespace name is prefixed with 'hello-' but ConfigMap namespace value isn't. I would either expect that namePrefix doesn't apply to literally declared Namespace or namespace references be tracked so that modifications done by kustomize are propagated like kustomize does with ConfigMap name hashing.

[Liujingfang1]

This should be related to the order of nameprefix transformer and namespace transformer. The correct order should be modifying the name prefix ahead of updating namespace field.
When namespace transformer is created, it accepts kustomization.Namespace as an argument. This argument should be updated by adding nameprefix.

[Liujingfang1]

I think about this again and tend to not add nameprefix to namespace. It is expected by users that name prefix and namespace of resources are the same as declared in kustomization.yaml. Adding a prefix to the namespace name is not in alignment with this expectation. @monopole What do you think?

[Liujingfang1]

Since the change is not backward compatible. We reverted it. Will add some deprecation message for current behavior in our next release (v1.0.6). This change will be added in a future release

[monopole]

Just observing (for my own memory) that you added the deprecation message. Thanks! I know we're getting another release ready.

[him0]

I have a question. I have namespace resource for production is following

base/namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: world

And I'm using namespace dev-world in development environment, so I am using following.

overlayers/development/kustomization.yaml

namePrefix: dev-
namespace: dev-world
bases:
- ../../base

This kustomization.yaml generate following namespace resource, and it make new namespace 'dev-world'.

base/namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: dev-world

When namePrefix will be not apply to namespace resource, how to make different name namespace?

[symfrog]

@him0 I used a JSON patch for this purpose. For example, the following patch could be added to the overlay's kustomization.yaml:

patchesJson6902:
- target:
   version: v1
   kind: Namespace
   name: world
  path: patch_namespace.yaml

in patch_namespace.yaml:

- op: replace
  path: /metadata/name
  value: dev-world

@Liujingfang1 not sure if this is idiomatic or if a more idiomatic way exists?

[mr-karan]

I'm using KustomizeVersion:3.1.0 but still facing the same issue.

namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: myapp

kustomization.yaml

resources:
- namespace.yaml
namespace: myapp
namePrefix: myapp-

End result on doing kustomize build:

apiVersion: v1
kind: Namespace
metadata:
  name: myapp-myapp

[surki]

Looks like this change didn't make it out. I am using with the following patch:

```diff --git a/plugin/builtin/prefixsuffixtransformer/PrefixSuffixTransformer.go b/plugin/builtin/prefixsuffixtransformer/PrefixSuffixTransformer.go
index 80c57462..96c6959f 100644
--- a/plugin/builtin/prefixsuffixtransformer/PrefixSuffixTransformer.go
+++ b/plugin/builtin/prefixsuffixtransformer/PrefixSuffixTransformer.go
@@ -32,6 +32,9 @@ var prefixSuffixFieldSpecsToSkip = []config.FieldSpec{
{
Gvk: gvk.Gvk{Kind: "CustomResourceDefinition"},
},

• {
• Gvk: gvk.Gvk{Kind: "Namespace"},
• },
  }

func (p *plugin) Config(
```

@Liujingfang1 ?

[leojonathanoh]

I'm using KustomizeVersion:3.1.0 but still facing the same issue.

namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: myapp

kustomization.yaml

resources:
- namespace.yaml
namespace: myapp
namePrefix: myapp-

End result on doing kustomize build:

apiVersion: v1
kind: Namespace
metadata:
  name: myapp-myapp

same issue. I have a single namespace, and want to add a prefix/suffix to a base of resources. Turned out everything is ok except now the namespace has a prefix/suffix, and now there's a mismatch between the namespace of the namespace.yaml and other .yaml resources.

@mr-karan did you manage to workaround it?

[mr-karan]

Yes I found a workaround. The base should not have the namespace.yaml. You can have the namespace.yaml in your overlays folder where you define namePrefix/suffix.

Something like this works

[leojonathanoh]

Yes I found a workaround. The base should not have the namespace.yaml. You can have the namespace.yaml in your overlays folder where you define namePrefix/suffix.

Something like this works

@mr-karan
thanks, this is helpful.

In my case I had to keep my base in fully working order, so i had to keep namespace.yaml in the base. So I ended up with patchesJson6902 and namespace-patch.yaml in each overlay based on @symfrog's workaround, changing the namespace name back to its original name:

base/kustomization.yaml

namespace: my-namespace
resources:
- namespace.yaml
- ...

base/namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace

overlay/my-overlay/kustomization.yaml

namespace: my-namespace
bases:
- ../../base
resources:
- ...
nameSuffix: -foo

# Workaround the fact that namePrefix / nameSuffix also adds a prefix to the base namespace. Issue: https://github.com/kubernetes-sigs/kustomize/issues/235#issuecomment-522887625. Workaround: https://github.com/kubernetes-sigs/kustomize/issues/235#issuecomment-430197657
patchesJson6902:
- target:
    version: v1
    kind: Namespace
    name: my-namespace
  path: namespace-patch.yaml

overlay/my-overlay/namespace-patch.yaml

- op: replace
  path: /metadata/name
  value: my-namespace

This could really be more elegant, but at least it makes it easy to run a dozen or more very similar "stacks" all in the same namespace. At least for my use case. Hope it helps someone.

[surki]

@leojonathanoh I am using json patch workaround.

@monopole Can we re-open this issue? Or do you prefer opening a new one?

[schaze]

Can this be picked up again please? I am not sure why an issue which has (apparently) a working fix but is not actually fixed stays closed? This problem is a real annoyance for a lot of people and I for my part am getting tired of having to patch/fix these "strange" behaviors out of kustomize in my yamls (same goes e.g. for the commonLables problem with the selectors in netowrkpolicies...).

[ant31]

Same problem here, namespace should be excluded or at least we should have an easy way to do it.

[alwaysastudent]

Can this be reopened?

[oblogic7]

Just ran into this one myself. Would be nice to have a clean way to handle this.

[vplme]

There is a more recent identical issue (https://github.com/kubernetes-sigs/kustomize/pull/2742) that was closed recently because a merged PR (https://github.com/kubernetes-sigs/kustomize/issues/1899) fixes this issue. So I guess it is just waiting for the next release.

[elmariofredo]

I can confirm that this was released as part of v3.8.2