Why does the direct policy attachment only attch one object?

[SpecialYang]

For example, I want to apply retry policy for two routes of all routes. I have to create two retry polices to these two routes individually even if they have the same retry polices.

[arkodg]

+1 for guidance of a targetRef as a list

[robscott]

This is a good question. At this point we're trying to avoid adding additional complexity to a system that is already quite complex. At this point we're trying to focus all our efforts around policy attachment to making it easier to understand and work with (x-ref #2012). Until we can solve that, I think we'll be very hesitant to add any additional complexity here.

[hzxuzhonghu]

Maybe not relevant: have one case if retry policy 1 targeted for a route A, while retry policy 2 is also targeted to route B, then what's the expected result?

Any way can we prevent such misusage

[sanjaypujare]

I strongly support this request. For policies to be useful/usable one should be able to attach them to multiple objects (routes). Also I don't think we need to wait for #2012 to be resolved.

[sanjaypujare]

The problem of discoverability/visibility of all policies affecting a resource seems orthogonal to the limitation that a policy (metaresource?) can target only one object. Removing this limitation does not add to the complexity of #2012 unless I am missing something.

[youngnick]

The original idea is that if you want to affect more than one object, you should be using an Inherited Policy and attaching that inherited policy higher up the object tree. Yes, this is basically designed-in friction to make people think about their Policy design.

That meets the requirements of being able to affect multiple objects while not increasing the overall complexity of the Policy object.

[sanjaypujare]

Got it, makes sense. @robscott said something similar in an offline discussion.