Curated functions should use CRD for advanced config

[Shell32-Natsu]

set-label and set-annotation are using ConfigMap for advanced config in a wrong way.

Needs to rewrite this part in set-label, set-annotation and set-namespace.

[mengqiy]

Function config should have schema if it's more than simple key-value pairs. Having schema can enable other tools e.g. IDE can use the schema to help function users write function config. It doesn't need to be a real server-side CRD, but it can be a client-side equivalent of CRD (i.e. looks like a KRM but doesn't need to be installed in the server). kubebuilder can be used to generate client-side CRDs https://book.kubebuilder.io/reference/generating-crd.html

[Shell32-Natsu]

Use kubebuilder to generate CRD schema sounds very good to me.

[Shell32-Natsu]

According to KRM function spec, the function config CRD should be put in functionConfig field in the ResourceList.

Example layout for the function config CRD:

apiVersion: kpt.dev/v1
kind: SetNamespace # depending on function
metadata:
  name: SetNamespaceConfig
# particular fields depend on function
namespace: test
fieldSpecs:
- path: sepc/selector/namespace
  group: MyGroup
  Kind: MyResource
...

apiVersion: kpt.dev/v1
kind: SetLabel # depending on function
metadata:
  name: SetLabelConfig
# particular fields depend on function
labels:
- labelName: foo
  labelValue: bar
  fieldSpecs:
  - path: sepc/selector/label
    group: MyGroup
    Kind: MyResource
...

[mengqiy]

That looks like one client-side CRD per function. What you have here are CR instances. We need to have their corresponding CRD with OpenAPI schema. When a user provides an advanced config, we can validate it against the OpenAPI schema.

For Golang-based fn, we can define the go struct and then let kubebuilder to generate the CRD from go struct.

[Shell32-Natsu]

Yes I suppose we need to have one CRD per function. Will create PR to implement it in Go.