-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend API to support wildcard match/replace on FieldSpec level. #4456
Comments
@yuwenma: This issue is currently awaiting triage. SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the The 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. |
I think the use case you've described is what the replacement filter is for. Have you tried it out? It will also soon support a wildcard match (#4424) If the replacement filter is unsuitable, could you provide an example where it cannot do what you need? Or provide some other feedback if it is too confusing to use. There are some examples of what the filter can do in the tests. |
Thanks for the pointer. The wildcard support in replacement transformer #4424 is on the fieldspec path. I'm expecting to wildcard match the value of that fieldspec scalarNode. I think they are extending the API from different aspects :) Yeah, I tried replacement filter and it's currently the only workable approach to replace a field if not using a setter. Overall, replacement transformer provides the general solution. KRM fn authors may want some simpler, dedicated solutions. |
Let's discuss in tomorrow's contributor meeting, I added it to the agenda. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closing this issue. In response to this:
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. |
Is your feature request related to a problem? Please describe.
I want to use the fieldSpec filter to update the node value based on the its current value in that fieldSpec. This requires getting the current fieldSpec value. However, there's no easy way I can get the value (fieldSpec filter only allows me to create or set it)
Describe the solution you'd like
I want the fieldSpec type to have a new attribute
regexPattern
that allow me to pull out the current value.e.g. the fieldspec of my KRM API obj
.spec.refTo
has valueprojects/yuwen-project/locations/us-central1
which is in the pattern ofprojects/${project}/locations/${location}
. If I want to update the location value only, I can define aSetValue
to pull theprojects/yuwen-project/locations/
part viafieldspec.regexPattern
and attach the new location to construct the new value.Describe alternatives you've considered
Add "GetValue" function to fieldspec filter.
The function GetValue itself is helpful and can be added to the filter. In my use case, the regex pattern itself is an attribute of the fieldspec type. The way current transformer plugin/builtin works is to unmarshal yaml fieldspec patterns. To be aligned with the current transformers, it is intuitive to make the regexPattern an attribute of fieldSpec.
The text was updated successfully, but these errors were encountered: