Support for required function parameters

[morgante]

I would like a way to mark a function parameter as required in a Kptfile, such that the package consumer must provide their own value for it (no default is available).

Based on setting a parameter as required, I'd like the following features to be possible:

• Machine-parseable, so that we can auto-generate documentation
• Listed as a required customization in any info CLI commands
• If I attempt to run other kpt commands (ex. kpt live apply) without filling in a required customization it should fail fast

Describe alternatives you've considered

These can be documented separately but that is inconsistent and error-prone.

Additional context

kpt 0.3x supported required setters.

[mikebz]

@phanimarupaka @frankfarzan @droot - heads up, this needs design work. Originally slotted to post v1 in a conversation with @bgrant0607 but seems like a potential usability speedbump for LZ customers.

[morgante]

@mikebz We don't necessarily need to block the v1 launch on it, but it's definitely a fast-follow item.

[bgrant0607]

Function parameter descriptions and declarative validation are needed.

For required vs optional, I like delegating that to the Kptfile rather than to the function metadata. The user could toggle the property as necessary.

Another way we could possibly treat it is as a priority spectrum: P0 must be set, P1 would be recommended, P2 would be optional, P3 would be unlikely to be changed. Or we could use words for that: an enum rather than a bool: required, recommended, optional, advanced. Or something like that. To facilitate progressive disclosure.

[phanimarupaka]

Function parameter descriptions and declarative validation are needed.

This is something in our radar already. We are trying to figure out the right UX for package publishers to provide the validation rules for function parameters without loosing the simplicity of model. These rules can also be consumed by Cloud Code to provide authoring assist to users.

For required vs optional, I like delegating that to the Kptfile rather than to the function metadata. The user could toggle the property as necessary.

There are 2 layers here.

1. Function author sets few obvious rules on function parameters. For e.g. set-namespace function needs namespace parameter to be passed. Package publisher need not worry about that.
2. Package publisher can set additional rules. For e.g. The namespace parameter should have my-org prefix and should be of maximum length of 10 chars.

Another way we could possibly treat it is as a priority spectrum: P0 must be set, P1 would be recommended, P2 would be optional, P3 would be unlikely to be changed. Or we could use words for that: an enum rather than a bool: required, recommended, optional, advanced. Or something like that. To facilitate progressive disclosure.

[bgrant0607]

Kustomize uses KRM types for function inputs: https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2906-kustomize-function-catalog https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2299-kustomize-plugin-composition

That provides a means for defining the input schemas -- CRDs.

If we were going to go that route, we'd want a kubebuilder-like mechanism in the function SDKs to generate the CRDs: https://book.kubebuilder.io/cronjob-tutorial/new-api.html

We'd also want extensible kubegen-like tooling to generate the 5+ lines of boilerplate for each individual function input object.

The catalog mechanism could also automatically map types to functions without explicitly specifying the functions in every Kptfile.

@justinsb