Gateway override merge strategy dependant on policy creation order

[martinhesko]

During test development, I noticed this only in a case where I had 2 policies targeting the same Gateway, with one providing a merge override.

Steps to reproduce

Policy 1:

spec:
  limits:
    gateway_limit:
      rates:
        - limit: 3
          window: 5s
      when:
        - predicate: request.path == '/anything'
    route_limit:
      rates:
        - limit: 10
          window: 5s
      when:
        - predicate: request.path == '/get'

Policy 2:

spec:
  overrides:
    limits:
      route_limit:
        rates:
          - limit: 3
            window: 5s
        when:
          - predicate: request.path == '/get'
    strategy: merge

• Create policy 1 first targeting the gateway
• Create policy 2 targeting the same Gateway, the policy provides a complete override to Policy 1 instead of Policy 1 staying partially enforced as expected

If Policy 2 is created first it works as expected, with Policy 1 being partially enforced.

[guicassolato]

I think what's described is the expected behaviour, i.e. there's no bug IMO.

The strategy declared by a policy only applies to the policies that are lower than that policy in the hierarchy.

In the example provided, both policies target the same level, but Policy 1 is created first. Therefore, Policy 1 > Policy 2¹. In this case, the strategy implicitly declared by Policy 1 (i.e. atomic defaults) dictates the behaviour, and the fact that Policy 2 declares merge overrides means nothing.

Footnotes

1. See Conflict Resolution in GEP-713. "The older Policy based on creation timestamp beats a newer one." ↩