Skip to content
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

Closed
yuwenma opened this issue Feb 7, 2022 · 8 comments
Closed

Extend API to support wildcard match/replace on FieldSpec level. #4456

yuwenma opened this issue Feb 7, 2022 · 8 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@yuwenma
Copy link
Contributor

yuwenma commented Feb 7, 2022

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 value projects/yuwen-project/locations/us-central1 which is in the pattern of projects/${project}/locations/${location}. If I want to update the location value only, I can define a SetValue to pull the projects/yuwen-project/locations/ part via fieldspec.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.

@yuwenma yuwenma added the kind/feature Categorizes issue or PR as related to a new feature. label Feb 7, 2022
@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Feb 7, 2022
@k8s-ci-robot
Copy link
Contributor

@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 triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

@natasha41575
Copy link
Contributor

natasha41575 commented Feb 7, 2022

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.

@yuwenma
Copy link
Contributor Author

yuwenma commented Feb 7, 2022

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.

@natasha41575
Copy link
Contributor

Let's discuss in tomorrow's contributor meeting, I added it to the agenda.

@k8s-triage-robot
Copy link

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:

  • 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 or PR as fresh with /remove-lifecycle stale
  • Mark this issue or PR as rotten with /lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

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

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 9, 2022
@k8s-triage-robot
Copy link

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:

  • 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 or PR as fresh with /remove-lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

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

/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jun 8, 2022
@k8s-triage-robot
Copy link

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:

  • 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 or PR with /reopen
  • Mark this issue or PR as fresh with /remove-lifecycle rotten
  • Offer to help out with Issue Triage

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

/close

@k8s-ci-robot
Copy link
Contributor

@k8s-triage-robot: Closing this issue.

In response to this:

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:

  • 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 or PR with /reopen
  • Mark this issue or PR as fresh with /remove-lifecycle rotten
  • Offer to help out with Issue Triage

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

/close

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

4 participants