Topic that needs more work.

We've figured out some aspects and requirements of package / function inputs:

• Packages are not encapsulated and don't have monolithic package-specific interfaces: https://kpt.dev/guides/rationale
• Setters are another form of manually specified parameters, and are not recommended: Document problems with setters / parameters, and alternatives #3131. We also ran into problems with composition of multiple packages when using setters.
• Individual attributes should be able to just be edited in place, since we store the rendered output and update it in place, and functions should "patch" resources in general, rather than blow them away Special behavior for generators #2528.
• KRM functions can take their inputs from a specified "function config", which is either a ConfigMap or a client-side KRM type, such as ApplyReplacements, which we should be able to automatically map to functions Map function inputs to functions automatically via a catalog mechanism #3339.
• We've noticed with value transformers Make it easier to write value transformers #3155, such as set-namespace and set-labels, that input values often need to be copied from their sources to the input structures expected by the functions.
• The variant-constructor pattern can use the package name to provide distinct identities for variants.
• We've identified the need for a deployment target "context", such as cluster targets Declarative cluster targeting #3387, along the lines of kubeconfig, gcloud config, terraform provider config, etc.
• Standardization of input types, APIs, across packages increase the opportunity for plug-and-play-style automation
• There may be other properties associated with the variant "context" that we need to discover or users need to provide. If the latter, we may need to be able to identify those attributes automatically, so that we can prompt the user. Multiple sources of context are common, such as environment and application.
• We need to be able to find sets of input contexts in order to automatically generate corresponding sets of deployment packages. Bulk package creation #3347
• We need to be able to identify downstream inputs in order to implement a "replay" approach to package upgrades. Fixing updates in porch #3329
• We want to support loosely coupled external dependencies, such as an application package like ghost requiring a namespace or a SQL database
• Fully dynamic data, like autoscaled replica counts, may not belong in config storage. Another common example is allocated IP addresses, for which service discovery systems and DNS are common. But there may be some that we want to "snapshot" and write to storage. GitOps image updaters are an example.
• Some inputs may be reasonably self-contained, such as application config for ConfigMap generation ConfigMap generation #3119.

But we don't have a fully fleshed out model or recommended patterns yet.

kpt isn't the first config tool to encounter these issues. We should look at data-oriented, non-package-parameter-based models for inspiration.

Some examples:

• Puppet's facter and hiera. Core facts are kind of like standardized context.
• Ansible inventory. Ansible was described as infrastructure as data. Example of separating out input data.
• Terraform data sources. Example
• Kapitan inventory. Video. Generator reference.
• Various runtime parameter stores: Consul, Pulumi config, etc.

Additional thoughts or findings should be posted back here.

cc @justinsb @johnbelamaric @droot @yuwenma