Proposal: Replacements and Patch value in the structured data
This proposal decides the interfaces to change values in the structured data (like json,yaml) inside a Kubernetes objects' field value and implements changing function target a few formats (mainly json).
appendix
- https://github.com/kubernetes-sigs/kustomize/issues/4517
- https://github.com/kubernetes-sigs/kustomize/pull/4518
Hi @koba1t. Thanks for your PR.
I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.
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.
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: koba1t
To complete the pull request process, please assign knverey after the PR has been reviewed.
You can assign the PR to them by writing /assign @knverey in a comment when ready.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
/ok-to-test
@koba1t: This PR has multiple commits, and the default merge method is: merge. You can request commits to be squashed using the label: tide/merge-method-squash
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.
Hi, @natasha41575.
Sorry for the delay to reply. I fix from your feedback. (And add details from #680 (comment)) Could you recheck it?
Thank you! Will take another look later this week
Have been on vacation for a couple weeks, will do another pass soon. Thank you for being patient!
Hi @KnVerey Thanks for your comments. I'm working to improve this proposal. If you have time, could you recheck my fix and comment on my ideas?
@KnVerey do you have time to give this proposal another pass?
What happens if the format is not JSON. Still structured, but perhaps a less common format?
Hi @KnVerey, Could you recheck this proposal?
/triage under-consideration /priority important-longterm /kind feature
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle stale - Close this PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
@natasha41575 @koba1t @KnVerey Any updates or projected timeline on this feature? This feature would resolve an issue that our management regularly mentions as a big drawback for kustomize.
We often run into this scenario: a kubernetes deployment has been configured to read in a config file config.yaml mounted into the pod via a configmap's structured string data field. This multiline string data field is typically in yaml or json format. We discover that we need to set some of these config items for a particular site or particular customers deployment and immediately increase the estimated completion time/level of effort when we realize the config in question is inside a structured string. We have had to solve this issue in a multitude of "creative" ways, for example:
- If open source, we hope they added an environment variable override so we can patch that into the deployment
- If we own the code, we modify the code and rerelease with environment variable overrides for all configs that may need patching
- If there is no env override, sometimes there is a unique replacement that will work (delimit on " and replace the 42nd value for instance)
- Some scenarios we can copy and paste the entire structured string into the patch and make the small modification we need
- Use kustomize to move the configmap mount to an init container that updates the configfile based on env variables and writes out the desired config to a shared volume mount where the application was originally configured to read from
This feature would not only save time/money but also improve the readability and maintainability of our code base. We'd love to see this prioritized and merged as soon as possible!
https://github.com/kubernetes-sigs/kustomize/issues/3787 https://github.com/kubernetes-sigs/kustomize/issues/4517
Once this is merged, I'll be interested to see what gaps (in existing vars functionality) remain to be filled.
I created a discussion in hopes of clarifying the current deficits, as well as plans to address them:
https://github.com/kubernetes-sigs/kustomize/discussions/5046
/lgtm cancel
Ongoing discussion in https://github.com/kubernetes-sigs/kustomize/pull/4558#discussion_r1421029039, should get resolved soon
/lgtm /approve
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: koba1t, natasha41575
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [koba1t,natasha41575]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment