-
Notifications
You must be signed in to change notification settings - Fork 336
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
targetRef matching API improvements #8681
Comments
Maybe we can structure the types such that you can't use both |
xref #8155
|
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. |
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. |
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. |
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. |
Description
It's not always clear how to call functions like
MatchedPolicies
and what to do with the results without digging into implementation. For single item rules sometimes we call.Compute
on it like herekuma/pkg/plugins/policies/meshproxypatch/plugin/v1alpha1/plugin.go
Line 41 in 4b04a60
Rules[0]
kuma/pkg/plugins/policies/meshtrace/plugin/v1alpha1/plugin.go
Lines 134 to 135 in 60024ab
The algorithm is nicely documented on the website https://kuma.io/docs/2.5.x/policies/targetref/#understanding-targetref-policies but I think we could do a better job explaining in code what's what and how to use it.
Tagging @lobkovilya because he probably knows best.
The text was updated successfully, but these errors were encountered: