Open slonka opened 9 months ago
Maybe we can structure the types such that you can't use both
xref https://github.com/kumahq/kuma/issues/8155
Triage: both ways are correct. We could unify those occurrences of the code. Also consider documenting .Compute function.
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant, please comment on it or attend the next triage meeting.
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant, please comment on it or attend the next triage meeting.
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. If you think this issue is still relevant, please comment on it or attend the next triage meeting.
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 here https://github.com/kumahq/kuma/blob/4b04a600230b2598f516017a1d5e3abdabe10001/pkg/plugins/policies/meshproxypatch/plugin/v1alpha1/plugin.go#L41 (and why is MeshSubset hardcoded not taken from targetRef?) and sometimes we just get theRules[0]
https://github.com/kumahq/kuma/blob/60024abf3876297acb668f55773e883e21823961/pkg/plugins/policies/meshtrace/plugin/v1alpha1/plugin.go#L134-L135 - which one is correct? what about From/To rules?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.