Localize plugins as Kustomizations

[annasong20]

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?

The kustomize localize command should localize file references in built-in plugins, which are specified as Kustomizations.

The alpha version of the command only localizes file references in built-in plugins specified as a file or inline yaml. Built-in plugins are the Kubernetes resource versions of native Kustomize fields like patches and configMapGenerator. They can be specified under the generators, transformers, and validators Kustomization fields as the resource itself or a Kustomization that outputs said resource. When a built-in plugin is in the form of a Kustomization, the command needs to localize both the Kustomization fields that

• can hold file paths
• target plugin fields that can hold file paths

Why is this needed?

This feature completes the set of files that kustomize localize can and needs to make available locally. This feature is implied as necessary to graduate the command to beta. See umbrella task #5125 and the command's KEP.

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

The only alternative is for the user to manually download and replace urls.

What other solutions have you considered?

The command could also blindly try to localize any values that look like file paths or urls, but this wouldn't be very safe for the user. Kustomize would then be checking the user's file system and making network requests in an unauthorized manner.

Anything else we should know?

This feature will likely need a code design discussion before implementation due to its complexity.

Feature ownership

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

[annasong20]

/triage accepted

[ezzoueidi]

/assign

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[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