Add target section for all kustomize transformers

[abogdanov37]

Eschewed features

• This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

Add a target section for all transformersl like in patch
Example
In patch section I can to select entities by name

patches:
  - path: patches/patch-name.yaml
    target:
      kind: LogConfig
      name: entity-name

I want to use that behavior in all transformers
Example
in label section I WANT to select entities by name

labels:
- pairs:
    service.org.com/name: service-name
    service.org.com/version: 0.1.0
  includeSelectors: true
  target:
    name: entity-name

Why is this needed?

Because I want to create many level customize builds
Example
Application 1 depends on service 1 that depends on service 2
I create

1. kustomize.yaml for Application 1
2. kustomize.yaml for Service 1
3. kustomize.yaml for Service 2

If I use labels section in Service 1

labels:
- pairs:
    service.org.com/name: service-name 1
    service.org.com/version: 0.1.0
  includeSelectors: true

and Service 2

labels:
- pairs:
    service.org.com/name: service-name 2
    service.org.com/version: 1.1.0
  includeSelectors: true

The labels from Service 1 replace labals from Service 2
That behavior repeat in all transformers besause they based only on kind field

Can you accomplish the motivating task without this feature, and if so, how?

Yes I can. I can use patch section instead of all transformations/
Example add labels

- op: add
  path: /metadata/labels
  value: {}
- op: add
  path: /metadata/labels/service.org.com~1name
  value: service-name
- op: add
  path: /metadata/labels/service.org.com~1version
  value: 0.1.0

What other solutions have you considered?

Have no other ideas

Anything else we should know?

No response

Feature ownership

• I am interested in contributing this feature myself! 🎉

[abogdanov37]

Hi! Any solution about triaging?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[stormqueen1990]

/remove-lifecycle stale /assign

[stormqueen1990]

It would be nice to have a way of applying labels in a fine-grained way as proposed.

/triage under-consideration
/unassign

[abogdanov37]

It would be nice to have a way of applying labels in a fine-grained way as proposed.

/triage under-consideration /unassign

Hi @stormqueen1990! Assign this ticket to me please. I will start to work on it after finish that PR #5678

[stormqueen1990]

Hi there, @abogdanov37! 👋🏻

Because this changes the way that transformers and configurations process resources, an enhancement proposal will be needed before an implementation is made. If you're interested in writing that, please check out https://github.com/kubernetes-sigs/kustomize/blob/master/proposals/README.md#option-2-mini-in-repo-enhancement-proposal

You should also be able to assign the issue to yourself when you start working on it using /assign, but feel free to ping if you need any assistance!

cc: @koba1t

[koba1t]

HI @abogdanov37

I worry that the proposal is dangerous and could easily break the output.
I feel that the feature’s attempt to filter input before the transformer breaks consistency. That feature requests are overlooked in cases where one transformer entry affects multiple resources, such as when the name transformer changes both the configMap name and configMapRef in a pod.

I think there is a safe way to implement a filter function for each transformer.
Could you consider whether you know any reason to use a common interface for all transformers?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[abogdanov37]

/remove-lifecycle rotten