Support and document the variant-constructor pattern

[bgrant0607]

When creating a variant of a package (similar to variants in kustomize), it needs to be possible to change the names (and/or namespaces) of the resources in the package accordingly. Kustomize supports name prefix and suffix to make this simpler, but it's not set up automatically. One needs to build a tool on top of kustomize to generate variants (subdirectory, kustomization.yaml, name prefix/suffix).

Setting the names of objects is the #1 most common transformation applied to configuration packages across all systems and tools. The approach should be standardized across all packages of all types.

I propose 2 approaches:

1. A variant-constructor function should use the package name (by default) to perform this transformation. Convention over configuration. I commented with more details on Umbrella issue: Implement pipeline-aware function run workflows #1280 and ensure include-meta-resources is supported consistently across kpt fn commands #2184
2. A non-template-based way to specify that the package name should be used as an input to an existing function, like name prefix. It's possible that this could be solved in the function catalog through a convention for such an option for all functions that are suitable for use as variant constructors, since variant constructors likely need a way to override the default behavior anyway.

cc @mikebz @justinsb @droot

[droot]

+100

A non-template-based way to specify that the package name should be used as an input to an existing function, like name prefix. It's possible that this could be solved in the function catalog through a convention for such an option for all functions that are suitable for use as variant constructors, since variant constructors likely need a way to override the default behavior anyway.

Thinking out loud: since kpt pkg get updates the metadata.name field to the directory name of the pkg, we can extend that behavior and kpt can automatically parameterize the input for well known personalization functions such as set-namespace, ensure-name-substring if used in Kptfile. We can also support comment directives in Kptfile to disable the behavior. Now, if we want to support this generally for other functions as well, then we can support comment directive to enable this behavior.

If I zoom out a bit, it looks like a built-in hook for invoking some logic on kpt pkg get (one of the steps in the package lifecycle). Not sure if we would like to invoke the same hook on kpt pkg update as well or not.

[mikebz]

I think even a to command solution would be fine here, but the UX needs to be super easy.

$ kpt pkg get https://github.com/GoogleContainerTools/kpt.git/package-examples/wordpress@v0.7
...
$ kpt fn eval set-name -- $name

This is taking the smart defaults to the max. Knowing what image to use when no tag is specified, knowing that the fn name is provided when there is no -i, knowing that when there is no param name specified we put the value in the first parameters. Having a convention for some kpt provided values like package name ($name).

[droot]

So will be tackling this in current sprint that is starting today.

[bgrant0607]

I think this is more or less done.