Unable to disable commonLabels injection using transformer config: Error: conflicting fieldspecs

[jessesuen]

I am trying to to use the commonLabels feature, but without the behavior to inject the label into selectors by using transformer configs. According to the docs, I believe this is described as one of the use cases: "disabling adding commonLabels to fields in some kind of resources"

However, when trying to use transformer configurations to customize the behavior of commonLabels, I get the following error:

$ kustomize build
Error: conflicting fieldspecs

Here is a simple kustomization app which reproduces the behavior:

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

configurations:
- commonlabels.yaml

commonLabels:
  app.kubernetes.io/part-of: argocd

resources:
- service.yaml

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: redis
spec:
  selector:
    app: redis
  ports:
  - name: server
    port: 6379
    protocol: TCP
    targetPort: redis

commonlabels.yaml

commonLabels:
- path: metadata/labels
  create: true

- path: spec/selector
  create: false   # <<<<< I wish to disable this behavior
  version: v1
  kind: Service

[Liujingfang1]

Since .spec/selector is present in service.yaml

spec:
  selector:
    app: redis

you can't disable adding the commonLabel to this path by changing it to create: false.

Skipping certain paths in transformers is not supported yet, but is a reasonable requirement. Any thoughts or ideas on this would be really appreciated.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[acastle]

Has there been any additional thoughts on this one? As it stands there doesn't appear to be any way of overriding defaults specified in

kustomize/pkg/transformers/config/defaultconfig/commonlabels.go

Line 24 in 9bff2e8

- path: spec/selector

There are many situations in which this behavior is undesirable (e.g. commonLabels are entirely incompatible with headless services where the endpoints are explicitly created). Perhaps a mechanism for completely disabling the default configurations would be appropriate? I may be in the minority but, on first glance, this is how I expected these transformer configurations to function.

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jbrette]

Have a look here for the kustomize 3.2 out of the box solution. I personnaly find that it is unmaintainable because you have to copy/paste the transformer.yaml in base/staging and production in order to change the labels you want to apply.

If you use this PR Skip kustomize transformers for paths you will see that you will achieve the same result. But when you start to have base, staging, production....you will only have to put the commonlabels.yaml in one place. Your issue has been reproduced here.

This issue keeps coming up ( see #1567), and also it is not perfect and kind of difficult to use, kustomize 3.2.0 fixes your issue.

/cc @monopole @Liujingfang1 @septh-nr @richardmarshall @ian-howell

[richardmarshall]

@jbrette While I also have concerns about the maintainability of configuring internal plugins in this way, copying the transformer.yaml file around for bases and overlays isn't necessary.

Since the transformers (and generators) fields of the kustomization file are handled using the resource accumulator the paths specified there can be kustomization directories. This enables setting up a common "base" transformer config that can be reused by the various parts of the greater kustomization setup.

Using the transformer.yaml from your 3.2 example it could be moved into a new directory

labeltransformer/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- transformer.yaml

base/kustomization.yaml

...
transformers:
- ../labeltransformer
...

overlay/kustomization.yaml

...
transformers:
- ../labeltransformer
...

I still think we can improve the user experience for this, but at least using this model the config for the transformer can be stored in one place and there wouldn't be the challenges around keeping multiple copies in sync.

[jbrette]

@richardmarshall It flat out does not work. This is what I had difficulties getting the team to understand since we started the discussion.

1. You may want to reuse the fieldspec part of the transformer but not the "label/nameprefix /namespace". So you have to copy/paste all the fieldspec just to change one line or two (the nameprefix for one set to production- and the other one to staging-)....or your common labels (env:production for one and env:staging for the other). Have a look at canary like upgrade using kustomize for issue 0519. This example is using only transformers nothing in the kustomization.yaml. The fieldspec are copy pasted everywhere.

2. When you load a subdirectory, kustomize looks for the resources field and accumulate, not the transformers field. This is to some extend the same problem people encounter with sharing patches. You can't put a directory in the "patches" section. So if you want to inject an istio sidecar accross production and staging environment....you quickly end up in the diamond pattern.

[richardmarshall]

@jbrette It actually does work, at least the pattern of what I was trying to convey works, validated that it does before providing that example idea 😄

The transformer and generator configs are loaded using a completely independent accumulator from the one that is used for resources. Since it is scoped only to a single kustomization file including the same generator/transformer in various places doesn't run into the same issues as the accumulator used for the resources field.

For the other concern regarding wanting to tweak portions of the transformer config for various overlays (like the environment label example). While I think it's a bit mind bending you can leverage all the normal kustomization behavior for a transformer config that is defined as a kustomization directory. Can create an overlay for the transformer config which patches it to include additional fieldSpecs for example or add more labels to the set.

Pushed the test example I put together to validate this here: https://github.com/richardmarshall/kustomize-examples/tree/master/issue_817