First-class treatment of identifier transformations

[bgrant0607]

Related to #3155

This is the set-namespace transformer code:
https://github.com/GoogleContainerTools/kpt-functions-catalog/blob/master/functions/go/set-namespace/transformer/namespace.go

A previous version tried to update only namespace values matching the name of the Namespace resource:
GoogleContainerTools/kpt-functions-catalog#844

The problem with that was that it didn't work after kpt pkg update in the case that the upstream introduced a new resource with the original namespace name rather than the transformed namespace name. The desired behavior would be to remap all instances of the original namespace to the new desired namespace.

More generally, name changes are hard to do with just string munging. ensure-name-substring is an example of that:
https://github.com/GoogleContainerTools/kpt-functions-catalog/tree/master/functions/go/ensure-name-substring

We should do a deep dive into how kustomize manages name changes.

We need to explicitly model the object graph, including references to external dependencies, in order to support renaming and eventually other graph transformations.

Terraform, Pulumi, and other tools perform automatic naming and maintain aliases from declarative package-local names (kind of like formal parameters) to the actual resource names, which often contain unpredictable generated suffixes, similar to generated Pod names. In the case of Terraform, the resource names are generated from the module and resource structures, which is problematic when they get refactored.

Rather than (or in addition to) comments, we could annotate resources with the necessary metadata to maintain the mappings to their abstract names and namespaces. We've also discussed using the filenames, but in this case we want to be able to set the namespace of all resources that were in the same Namespace as the abstract Namespace ("example") in the blueprint, so we need that information. If there were references to those objects, we'd need to update those as well.

We were stripping the internal annotations in the package orchestrator, but either way we'd need to pass the annotations through the pipeline in order for them to be available to functions. We should just filter them in the UI rather than in porch.

There are non-KRM identifiers that may need similar transforms, also, such as Config Connector project ids.

cc @yuwenma @justinsb

[yuwenma]

Here's the design proposal. I'd like to keep that as a google doc for easy commenting and discussion. And I'll convert that to a PR in https://github.com/GoogleContainerTools/kpt/tree/main/docs/design-docs

[bgrant0607]

Thanks! I'm reviewing it. The analysis of kustomize's behavior definitely will be helpful to include in a design doc.

[wleese]

From slack: when copying multiple blueprints into a new deployable package for my application, I get this nice error about duplicate ConfigMap resource names. I blindly use the name "setters" for my setters.yaml config in multiple packages. I don't like the idea of giving them unique names manually, because say someone kpt pkg get's my package twice with different names. The Kptfile nicely has that (unique) name, but the setters.yaml doesn't.