Provide simple way of sharing transformers configuration.

[jbrette]

During the investigation of the best option to allow a user simple adjust the default configuration of builtin transformers, the idea was proposed to leverage kustomize transformers in kustomization.yaml.

The example here is adding a label "env: canary" in one kustomize context, and "env: production" in the other.

The current issue is that the commonslabeltransformer.yaml is basically copy/pasted from the canary to production and only the "labels" section changes.

Full example is available here

production kustomization.yaml look so:

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

resources:
- ../base

transformers:
- ./kustomizeconfig/imagetransformer.yaml
- ./kustomizeconfig/namesuffixtransformer.yaml
- ./kustomizeconfig/commonlabelstransformer.yaml
- ./kustomizeconfig/patchstrategicmergetransformer.yaml

The commonlabelstransformer.yaml for the production environment looks this way.

apiVersion: builtin
kind: LabelTransformer
metadata:
  name: labeltransformer
labels:
  env: production
fieldSpecs:
- path: metadata/labels
  create: true
  kind: Service
- path: spec/selector
  create: true
  kind: Service
- path: metadata/labels
  create: true
  kind: Deployment
- path: spec/selector/matchLabels
  create: true
  kind: Deployment
- path: spec/template/metadata/labels
  create: true
  kind: Deployment

On the canary side:

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

resources:
- ../base

transformers:
- ./kustomizeconfig/imagetransformer.yaml
- ./kustomizeconfig/namesuffixtransformer.yaml
- ./kustomizeconfig/commonlabelstransformer.yaml
- ./kustomizeconfig/patchstrategicmergetransformer.yaml

apiVersion: builtin
kind: LabelTransformer
metadata:
  name: labeltransformer
labels:
  env: canary
fieldSpecs:
- path: metadata/labels
  create: true
  kind: Service
- path: spec/selector
  create: true
  kind: Service
- path: metadata/labels
  create: true
  kind: Deployment
- path: spec/selector/matchLabels
  create: true
  kind: Deployment
- path: spec/template/metadata/labels
  create: true
  kind: Deployment

[jbrette]

/assign @monopole @Liujingfang1
/cc @richardmarshall @sethp-nr @ian-howell

[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

[cscetbon]

@jbrette Exactly the issue I'm facing. Any progress on that somehow ? I tried to patch the transformer loaded from the base but I got #2055 (comment)

[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.

[chancez]

/reopen

This is something I've struggled with as well. I'd love if there was an env var for global configurations to tell kustomize how to interpret various kinds of resources.

[k8s-ci-robot]

@chancez: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

This is something I've struggled with as well. I'd love if there was an env var for global configurations to tell kustomize how to interpret various kinds of resources.

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.

[pratikzingade]

I have the exact same issue, was anyone able to solve this problem?