Use replacement syntax for patch

[b1zzu]

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?

I want to use the replacement syntax which is more powerful than the patchesJson6902 but without using another resource as the source.

I would like to rewrite this:

replacements:
  - source:
      version: v1
      kind: ConfigMap
      name: cluster
      namespace: default
      fieldPath: data.HOSTNAME
    targets:
      - &ingress
        select:
          group: networking.k8s.io
          version: v1
          kind: Ingress
          name: cluster-prometheus-oauth2-proxy
          namespace: default
        options:
          delimiter: .
          index: 1
      - <<: *ingress
        select:
          name: cluster-grafana-oauth2-proxy
      - &deployment
        select:
          group: apps
          version: v1
          kind: Deployment
          name: cluster-prometheus-oauth2-proxy
          namespace: default
        fieldPaths:
          - spec.template.spec.containers.[name=oauth2-proxy].env.[name=REDIRECT_HOST].value
        options:
          delimiter: .
          index: 1
      - <<: *deployment
        select:
          name: cluster-grafana-oauth2-proxy

like this:

patches:
  - target:
      group: networking.k8s.io
      version: v1
      kind: Ingress
      labelSelector: component=internal-ingress
      fieldPaths:
        - spec.tls.*.hosts.*
        - spec.rules.*.host
      options:
        delimiter: .
        index: 1
    patch: example.com
  - target:
      group: apps
      version: v1
      kind: Deployment
      labelSelector: component=oauth2-proxy-deployment
      fieldPaths:
        - spec.template.spec.containers.[name=oauth2-proxy].env.[name=REDIRECT_HOST].value
      options:
        delimiter: .
        index: 1
      patch: example.com

Why is this needed?

Keep the configuration cleaner, and leverage the labelSelector to patch multiple resources at the same time.

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

I can achieve the same final result using replacement and ConfigMap

What other solutions have you considered?

Post kustomize variables substitution like Flux does [1]

1. https://fluxcd.io/flux/components/kustomize/kustomization/#variable-substitution

Anything else we should know?

No response

Feature ownership

• I am interested in contributing this feature myself! 🎉

[KnVerey]

cc @natasha41575 as the main author of replacements, but I believe we would prefer to address any shortcomings in Replacements rather than transferring the more complex syntax to the simpler patches transformer. If I understand correctly from the following:

Keep the configuration cleaner, and leverage the labelSelector to patch multiple resources at the same time.

part of the problem you have with using replacements is label selector support in targets. The good news is that already exists! Although it seems to be missing from the docs for some reason, it was introduced in #4229 and this test case is an example of how to use it:

replacements:
- source:
    kind: Deployment
    name: deploy-1
    fieldPath: spec.template.spec.containers.0.image
  targets:
  - select:
      labelSelector: foo=bar-1
    fieldPaths:
    - spec.template.spec.containers.1.image

The other shortcoming seems to be the need to source the replacement value from a resource:

I want to use the replacement syntax which is more powerful than the patchesJson6902 but without using another resource as the source.

One thing that is already possible is to put the config.kubernetes.io/local-config: "true" annotation on your ConfigMap so that it will not appear in the kustomize build output. Would you be happy with that solution in conjunction with the labelSelector field? Alternatively, what if Replacements supported an inline value as a source?

/triage needs-information

[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

[b1zzu]

Thanks, @KnVerey , both of your suggestions are perfect for my use case

[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

[ElSamhaa]

Although the local-config should work with this scenario, I'd like to have the option to define an inline value. In some situations, a complete dedicated local-config would be a little overkill.

[k8s-triage-robot]

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

This bot triages 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:

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

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

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

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

/close not-planned

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.