set-labels: added support for sourcing label values from other resources

[droot]

This PR adds support for specifying label values from fields in the other resources in the package.

An example setlabel configuration where we add myapp label and value comes from data.name field in package-context.yaml.

Note the labelsFrom. This change is also backward compatible since labelsFrom is new field.

# fn-config-setlabels.yaml
apiVersion: fn.kpt.dev/v1alpha1
kind: SetLabels
metadata: # kpt-merge: /set-labels
  name: set-labels
  labels:
    app: frontend
  annotations:
    config.kubernetes.io/local-config: "true"
    internal.kpt.dev/upstream-identifier: fn.kpt.dev|SetLabels|default|set-labels
labels:
  app: frontend
labelsFrom:
  - label: myapp
    source:
      kind: ConfigMap
      name: kptfile.kpt.dev
      fieldPath: data.name

/cc @yuwenma @natasha41575

Note: I tested this manually. Will add tests if y'all agree with the direction.

[yuwenma]

I plan to add a generic dynamic input support in the go SDK. Adding it directly to set-labels will introduce several problems. Currently I'd suggest use apply-replacement and set-labels together to achieve the same goal, and do not use a new approach.

[natasha41575]

Currently I'd suggest use apply-replacement and set-labels together to achieve the same goal, and do not use a new approach.

I was wondering the same thing. Is it too much to use apply-replacements to target this SetLabels resource to get the config you need?

[yuwenma]

Currently I'd suggest use apply-replacement and set-labels together to achieve the same goal, and do not use a new approach.

I was wondering the same thing. Is it too much to use apply-replacements to target this SetLabels resource to get the config you need?

It is. But the set-labels function is a curated function and we already have plans to change its functionConfig( yuanyi's original proposal). Adding a new feature ( i.e. the "labelsFrom" syntax) which we will have a more generic solution for (the go SDK) does not seem worth the user migration burden and the function owner's maintenance efforts.

[yuwenma]

@droot Is this a critical feature for Bank-of-Anthos? If so, I can prioritize this work and do it on the go-SDK side. Otherwise, I'd recommend we use apply-replacements and set-labels.

[wleese]

Would love to see this go in - currently using a workaround to push values into the set-labels function config