Kustomize: request nameSuffix to add suffix to resource names

[easeway]

Similar to namePrefix, but adding suffix to resource names helps unlocking a use case I'm currently facing:

My automated build pipeline will generate a Kubernetes manifest file containing resources, and I want the names of these resources to have a suffix which is generated from build number, because I need side-by-side deployment of old and new versions and give customer a smooth upgrade/rollback experience. Here's an example:

in the base:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp

And in a patch, I'd love to have kustomization.yaml include something like:

nameSuffix: -101

Where -101 is generated from build number in the automated pipeline. And ultimately get the manifest including:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-101

I've no idea if I can achieve this without something like nameSuffix. And definitely, I don't want to put build number as a prefix of all resource names.

[monopole]

Sounds good.

When kustomize generates configmaps and secrets, it makes a suffix for the resource names that is a hash of the contents. The generated resource gets a name like

  name: {namePrefix}{originalName}-{contentHash}

If we also have a nameSuffix customization, i suppose we should put it after the generated suffix, i.e.

  name: {namePrefix}{originalName}-{contentHash}{nameSuffix}

[Liujingfang1]

If we add nameSuffix, we can use the same transformer handling namePrefix.

@monopole For the generated ConfigMap/Secret, I expect the name to be

  name: {namePrefix}{originalName}-{nameSuffix}{Hash}

since the Hash is of both contents and the ConfigMap name.
When a namePrefix is added, the Hash changes. Similarly, when a nameSuffix is added, the Hash should also change.

[monopole]

The hash can depend on the prefix/suffix, but doesn't actually have to be placed at the end. If the user wants to specify a prefix/suffix, then there's an expectation that it's at the beginning/end.

Q to @easeway - why not a namePrefix of b101? i.e. just put a b before the build number.

[easeway]

@monopole putting build number as a prefix (regardless it's 101 or b101) is counter intuitive. Most of existing scripts/tools follow the convention that a build number is a suffix (or part of a suffix). Using namePrefix can generate the unique name with build number, however extra changes are required on existing scripts and tools.

[hagmonk]

namePrefix being a non-obvious value defeats/impedes things like tab completion with kubectl. And, just from an ergonomics perspective, it's quite jarring. I can't think of a single system where it's idiomatic to put version numbers or build identifiers before the human readable tag (maybe in RTL scripts??) ... I ended up here simply because I wanted to attach -production to the end of a deployment name :)

The way I see it: when dealing with identifiers, prefixes are things we attach when we want to namespace the identifier. Suffixes are things we attach when we create derivatives or specializations of the identifier.

In the world of Kubernetes, I find myself namespacing things using, well, namespaces. Or if I want to namespace really hard, using a separate cluster. So, personally, I'm not sure I'll ever need namePrefix. On the other hand, nameSuffix is what I need when I want to make a new variant of an existing app.

For instance, let's say I have kafka-streams-events as my base. I then want to create two deployments, who operate on Kafka topics baz and quux, and whose topics are selected by command arguments or environment variables. I want to create overlays for kafka-streams-events-baz and kafka-streams-events-quuz, simple as that.

[monopole]

@hagmonk thanks for that discussion and endorsement of this feature request. Ditto @easeway.

Which format for the name of generated resources?

1. {namePrefix}{originalName}-{contentHash}{nameSuffix}
2. {namePrefix}{originalName}-{contentHash}-{nameSuffix} (force the hyphen)
3. {namePrefix}{originalName}{nameSuffix}-{contentHash}
4. something else?

[hagmonk]

@monopole you're welcome, and I'm enjoying kustomize a great deal :)

It seems like 3. would provide the most consistency with with how other resources handle this. For example, when I work with Pods being scheduled by Deployments or StatefulSets, I have the expectation that a unique ID will be appended at the end. So that would feel natural to me here.

My original thought was that users should incorporate hyphens in their names as they see fit. The contentHash should separate itself with a hyphen in any case because a user may not supply a nameSuffix, and resources named like myconfigkhk45ktkd9 don't look very elegant :)

However, I can also imagine folks wanting a more "just do what I mean" approach. For example:

namePrefix | originalName | nameSuffix | output
--- | --- | --- | ---
backoffice- | broker-config | -production | backoffice-kafka-production-f3e3999d
backoffice- | broker-config- | production | backoffice-kafka-production-f3e3999d
-backoffice | broker-config | production-- | backoffice-kafka-production-f3e3999d

i.e. trailing and leading hyphens are stripped, and the (namePrefix, originalName, nameSuffix, contentHash) tuple is joined as a string with single hyphen separators.

It's a little more opinionated, but it would produce consistent results even in the presence of mistakes or typos. Users would have to really go out of their way to produce a resource name that looked out of place.

[Liujingfang1]

format 3 looks good to me.

The implementation for namesuffix support includes following main steps:

• Create a namesuffix transformer, it should implement the Transform interface. This will be similar to the nameprefix transformer.
• Pass the namesuffix to namesuffix transformer in a kustomization. This should be inside the file pkg/app/application.go. We need to create a namesuffix transformer here with the specified suffix string. Appended this transformer to the transformer list so that later it will be applied.

[Liujingfang1]

Does anyone want to contribute? This change is a good chance to get familiar with the Kustomize libraries and code base. You will learn the internal logic of how we handle base, overlays and different transformations. This change also has a good isolation from other parts so you don't need to worry about involved with many libraries at the same time.

[Liujingfang1]

Thanks to @fanzhangio for standing up to contribute. Let me know if you need any help

[schweikert]

@fanzhangio do you still plan to contribute this? I was thinking about doing it, in case you don't.

[jcassee]

Would this transformer be basically prefixname.go with the last line changed?

[Liujingfang1]

Fixed by #556, #550. Thank you @zoncoen