fn framework: Enable validation using openAPI schema for functionConfig

[KnVerey]

This introduces a new interface, ValidationSchemaProvider, and a new helper, SchemaFromFunctionDefinition(gvk resid.Gvk, data string) (*spec.Schema, error). Together, they enable a function author to use OpenAPI they have written to validate their inputs instead of manually writing the rules in the Validate() hook we already have (they can be used together, as the test show).

func (a v1alpha1JavaSpringBoot) Schema() (*spec.Schema, error) {
	schema, err := framework.SchemaFromFunctionDefinition(resid.NewGvk("example.com", "v1alpha1", "JavaSpringBoot"), javaSpringBootDefinition)
	return schema, errors.WrapPrefixf(err, "parsing JavaSpringBoot schema")
}

I used k8s.io/kube-openapi/pkg/validation/spec for this (instead of say, kubeval) for two reasons: we already depend on that package, and it is what the extensions API server appears to be using.

See also kubernetes/enhancements#3220, which makes the one change required for this to work for both KRMFunctionDefinition and CustomResourceDefinition. The advantage, as illustrated in one of the tests, is that you can use a tool like Kubebuilder to generate a CRD from your type structs, and then consume it directly with these new tools to get validation. Ideally we'd provide a bespoke KRMFunctionDefinition generator some day, but this should work nicely in the meantime.

This PR also defines the KRMFunctionDefinition type proposed in the KEP, since I need it for this feature. Alternatively, I could define only the subset of fields I actually need for this PR and/or make the type private for now--LMK if you want that.

/kind feature
/triage accepted
/cc @natasha41575 @mengqiy @jeremyrickard

[mengqiy]

Is this fact useful to users?

[KnVerey]

I came up with the PR while trying to use KubeBuilder to generate the schemas for me, so maybe? It's pretty neat: you annotate your types with Kubebuilder meta, run go generate, point an embed comment to the file, then point these new helpers to the embedded schema, and boom, super easy very thorough validations for your types.

[mengqiy]

Do we want to support reading from a Catalog kind?

[KnVerey]

Sure, we can have another helper for that once Catalog is in here / somewhere. I'd like to keep that out of scope of this PR though.

[mengqiy]

nit: we usually have this field on the top.

[mengqiy]

json and yaml tags are missing.
And FunctionSpec is not well aligned with the KRM fn schema. We should reconcile.

[KnVerey]

Definitely. That's part of the Catalog-in-Kustomize work though, right? We never want two versions of this that are different, so that's why I just went ahead and used what is already available, for now. (this field isn't relevant to my PR and could also be left off)

[KnVerey]

this should be aliased k8syaml for consistency

[natasha41575]

/lgtm

CI is complaining about a missing go.sum entry. I can re-LGTM when you fix that.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: KnVerey

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [KnVerey]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[KnVerey]

I was really confused until I finally realized the missing entry was in pluginator, not kyaml 😅
Updated!

[natasha41575]

/lgtm

[natasha41575]

FYI I'm expecting this to be fixed soon kubernetes/kube-openapi#279

So we can go back and clean up the places we're using sigs yaml after that PR is merged.

[KnVerey]

That's great! There will still be a few places we need to do it, to support decoding into k/k types and types using metav1 metadata. But the fewer, the better!