Prevent apply on missing setter value

[halvards]

Describe your problem

Kpt v0 allowed setters to be marked as required, and kpt live apply would error if the value wasn't set.

This feature was useful in situations where a package wouldn't work without the value being set, and where there was no possible default value that would work.

This prevents packages from being accidentally deployed in situations where they wouldn't work.

An example is the source setter in this package: https://github.com/GoogleCloudPlatform/gatekeeper-securitycenter/tree/main/manifests

Request: I'd like kpt v1 to have a mechanism to block packages being applied if they're incomplete.

This isn't a request for deep validation (e.g., "is the source name valid?"), but rather a reminder to package consumers that they've missed a step.

[phanimarupaka]

We are planning to address this problem as part of input parameters validation.

[mikebz]

@phanimarupaka do we have a bug for that? Might be good to link it here.

[phanimarupaka]

#2041

[marshall007]

We are planning to address this problem as part of input parameters validation.

@phanimarupaka input parameter validation would only occur during function execution (i.e. kpt fn render), right? Are you implying that the function pipeline will be executed implicitly as part of the live sub-commands in the future or would it still be up to the user to to call kpt fn render prior to running kpt live apply?

[phanimarupaka]

@marshall007 The details are not finalized yet. kpt v0.39 does the validation when you trigger kpt live apply, but kpt 1.0+ might(/not) do it during kpt live apply. We will take this request into consideration while designing the validation story.

[diviner524]

To add more datapoints, the exact same issue is appearing in GCP KRM blueprints:

GoogleCloudPlatform/blueprints#135

A "required" setter value is missing in setters.yaml, however blueprint users won't be able to detect this issue, until they run kpt live apply and then realize their GKE cluster cannot be enrolled into GKE membership.

At this stage, they need to do further troubleshoot, to understand it is because the default value of a setter "platform-project-id" does not work.

Considering cluster provision is a relative heavy operation, it will be great if users can at least be hinted of a missing setter value, before they apply the blueprint and have a GKE cluster created.