-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for required function parameters #2041
Comments
@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. |
@mikebz We don't necessarily need to block the v1 launch on it, but it's definitely a fast-follow item. |
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. |
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.
There are 2 layers here.
|
Kustomize uses KRM types for function inputs: 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: 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. |
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:
info
CLI commandskpt live apply
) without filling in a required customization it should fail fastDescribe alternatives you've considered
These can be documented separately but that is inconsistent and error-prone.
Additional context
kpt 0.3x supported required setters.
The text was updated successfully, but these errors were encountered: