*No* merging of policies

[alexsnaps]

This aims at providing a much simpler model than what #4 is proposing. It comes pretty close to using HTTPRouteFilter, as it lets you target the same granular "resource". It gets rid of merging policies, so that default & overrides are merely a way to stack policies and use the one that ends up "on top" of the stack, according to all the resolve rules of the Policy Attachment hierarchy.

[maleck13]

+1 to this description, clear and concise

[maleck13]

one thing that occurred to me might be to actually reflect this in the status of the HTTPRoute in a condition

[maleck13]

+1

[maleck13]

It also ensure no unlimited endpoints are exposed

[maleck13]

Yes I think reporting status in the RLP and in the HTTPRoute / Gateway is worth consideration
example on a condition of the HTTPRoute status we could add something like GVK name namspace enforced

[maleck13]

I think linking to kubernetes-sigs/gateway-api#1489 would make sense here also

[maleck13]

if there was a way to do this (for example if we proposed a GEP around third party filters), would this compliment the policy side? Does a filter at the gateway level make sense? I don't see how filters would solve the use case of wanting to set a default limit for all new endpoints

[maleck13]

I think the fact it is an optional complexity is the perfect balance at least until we hear otherwise via new use cases. You have the "target all of a resource by default" and given a way to cover more advanced use cases and targeting. I also like the fact that the default section stays focused on the actual domain (RL) and leaves the targeting as a separate piece

[maleck13]

I like that we can describe this relatively simply. That said I thnk we would want a good range of "example" policies to cover common use cases similar to how it is done for https://github.com/kubernetes-sigs/gateway-api/tree/main/examples/standard

[maleck13]

I really like the balance found here. I see this as a good way forward with RLP to solve some of the use cases we want to solve for gateway admins and developers. I would encourage us to do a PoC ASAP to boil this down to practice

[eguzki]

Looking good, indeed.

[guicassolato]

I'd suggest trying the same Policy Attachment exercise based on this approach as well, i.e. without merges. My guts say that it's going to be significantly easier... at least for Kuadrant 🙂

[guicassolato]

My guts say that it's going to be significantly easier... at least for Kuadrant 🙂

Update: My guts were wrong! I'm trying to solve use cases 1-5 of the exercise without merges and my head hurts a little.

In the first example here, the PaintPolicy was changed from override: { color: blue } to default: { color: blue }. (That allowed later creating an HTTPRoute that inherited blue by default, and then replaced it with green by defining its own route-level PaintPolicy.)

What if I didn't want to change from an override to a default in the first PaintPolicy targeting the Gateway, but to create an additional default: { color: yellow } for a special case (before any route is created)? I suppose I would modify the gw-level policy like this:

kind: PaintPolicy
spec:
  override:
    color: blue
  default:
    color: yellow
    when:
    - special case
  targetRef:
    kind: Gateway
    name: my-gw

I would expect then yellow at all routes where special case matches (which might still be overridden by a route-level policy) and blue for all other cases, i.e. where special case does not match.

What happens if I create that route-level policy?

kind: PaintPolicy
spec:
  default:
    color: green
  targetRef:
    kind: HTTPRoute
    name: foo-route

I imagine it would be a noop, because of the gw-level override still holding?

So to be able to get green at least at special case on foo-route, what should I do? Maybe...

kind: PaintPolicy
spec:
  default:
    color: green
    when:
    - special case
  targetRef:
    kind: HTTPRoute
    name: foo-route

So the owner of the HTTPRoute needs to be aware of the details in the first PaintPolicy attached to the GW, so it can be reasoned that in fact what's going to happen is:

kind: PaintPolicy
spec:
  override: # the part that cannot be changed as enforced by the gw override policy
    color: blue
  default: # the part that the gw default policy allows to be overridden
    color: green
    when:
    - special case
  targetRef:
    kind: HTTPRoute
    name: foo-route

?

[alexsnaps]

@guicassolato ... to your yellow/green question: yes.
These people writing these Policies would have to sync in this world. Most importantly tho, the "when" there, would need to specified within the same policy for the catch all to not apply to it. And eventually that "when" would need to be present as an HTTPRouteRule, i.e. a HTTPRouteMatch clause of an actual HTTPRoute.

[guicassolato]

@alexsnaps, I'm probably overthinking this but I still have to go through... Apologies in advance.

What step 5 of the Policy Attachment exercise asks is actually even simpler (tho possibly harder to solve) than what I exemplified here with the PaintPolicy, because it does not involve conditions.

At steps 1 and 2, an override policy is set at the level of the Gateway. No conditions there. Then, at step 5, a specific policy targeting an entire HTTPRoute is set. There's no conditions there either.

I still don't know how to fix this.

It looks like, without merging and without conditions, once you set an override at the level of the Gateway, there's no point in setting anything else at the level of the HTTPRoute, yes?

And if there, for an entire HTTPRoute, a legit exception to an override set at the level of a Gateway, that exception needs to be specified in the policy that targets the Gateway. We don't want to remove the override, so it won't fall apart for the other HTTPRoutes where the override still holds.

This in itself already means the problem cannot be solved without conditions... Some sort of condition.

Because it's going to be, for a given route, either the policy that targets the Gateway or the policy that targets the HTTPRoute – i.e. all in, no merging –, it won't suffice a condition that says "this override, except in case X" and then specify what the policy is when "case X" in a separate policy targeting the HTTPRoute. What to apply for "case X" needs to go in the policy targeting Gateway as well, thus not leveraging hierarchy.

To be fair, this is not a problem inherent of merging or not merging, but a problem inherent of how we identify the bits of a policy that can be overridden and the bits that cannot. No merging of policies I guess only means less granularity to those bits, maybe?

Anyway, this thing that identify the bits seems to be pointing so far to the "conditions", but not any kind of condition; only the ones the control plane can reason about, practically ruling out what we've been calling "soft conditions".

Back to the case of the default set at the level of the Gateway and the attempt to override it with a policy targeting the HTTPRoute, which seems a problem easier to solve than the problem of the override with one exception without condition...

To me, it doesn't make sense to have a default and an override block in the same policy targeting the Gateway without any conditions at all. So, imagine the default is for a special case and the override is for all the rest (exactly like in my example with the PaintPolicies).

You said:

the "when" there, would need to specified within the same policy for the catch all to not apply to it.

Do you mean adding a kind of !special case condition to the part that goes in the override block?

kind: PaintPolicy
spec:
  override:
    color: blue
    when:
    - !special case
  default:
    color: yellow
    when:
    - special case
  targetRef:
    kind: Gateway
    name: my-gw

Then you said:

And eventually that "when" would need to be present as an HTTPRouteRule

There are two possibilities here: a "hard" (route-related) condition and a "soft" (non route-related) condition.

If special case is route-related, I don't think negating it (i.e. !special case) is supported by Gateway API, is it? Maybe this invalidates the previous recommendation? (If I even understood the recommendation correctly in the first place.)

If special case is NOT route-related, then likely the two rules there can hardly be reasoned in terms of the "identity of the rule" by the control plane, i.e. if they mean yellow and blue for the same context or for two different contexts. Therefore better if the conditions are processed as what we've been calling "soft conditions" by whatever ultimately enforces the policy in the data plane (Limitador, Authorino, or the "Painter" apparently).

This raises a hypothesis that, for all that matters, to the control plane, soft conditions are just like having no conditions at all.

Imagine the HTTPRoute exists but no policy was attached to it; it's only that one policy targeting the Gateway, with one override and one default and the two "soft conditions" (!special case and special case, respectively). Is blue deemed to apply to all cases because it's an override and we cannot reason about the relation it has relatively to yellow based on soft conditions? Or, on the other hand, if yellow or blue are really to be decided based on soft conditions – and therefore both bits of the policy need to be pushed to the data plane –, then the override and the default keywords there mean nothing at all?

I imagine it's the latter case, i.e. overrides and defaults only having meaning when dealing with conflicts between policies, but nothing between them within a same policy.

So, now, if we do create the second policy green targeting the HTTPRoute, while the conditions are "soft conditions", there's nothing the control plane can do for working out the relations and therefore traffic will always be either blue or yellow but never green?

(And from here I refer back to the beginning of my comment where override with no "hard" conditions equals to no leveraging of hierarchy.)

[alexsnaps]

superseded by #58