Add target section for all kustomize transformers

abogdanov37 commented 5 months ago

Eschewed features

[X] 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

kustomize.yaml for Application 1
kustomize.yaml for Service 1
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

[X] I am interested in contributing this feature myself! 🎉

abogdanov37 commented 5 months ago

Hi! Any solution about triaging?

k8s-triage-robot commented 2 months ago

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 commented 2 months ago

/remove-lifecycle stale /assign

stormqueen1990 commented 1 month ago

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

/triage under-consideration /unassign

abogdanov37 commented 1 month ago

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 https://github.com/kubernetes-sigs/kustomize/pull/5678

stormqueen1990 commented 1 month ago

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 commented 1 month ago

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?

kubernetes-sigs / kustomize