Improved status for RateLimitPolicy

[maleck13]

What

The RateLimitPolicy status should aggregate the status of the WASMPlugin any EnvoyFilters, HTTPRoute and also the RateLimit limitador resource. The RateLimitPolicy API is the end user facing API and it should communicate well the current state of the rate limiting set up.

Initially the status can reflect wether the ratelimit, envoyfilter and WasmPlugin has been created and the HTTPRoute is accepted. Possibly we want to add some new conditions as we are interacting with two different systems perhaps a condition for Gateway and a condition for RateLimitService and then a general Ready condition. alternatively we could use the Ready condition with specific messages to communicate. Our status block for AuthPolicy should follow the same pattern we decide on here

status:
  conditions:
    - lastTransitionTime: "2019-10-22T16:29:24Z"
      status: "True"
      msg: "gateway configured correctly"
      type: Gateway
    - lastTransitionTime: "2019-10-22T16:29:24Z"
      status: "True"
      mgs: "rate limit service configured correctly"
      type: RateLimitService
    - lastTransitionTime: "2019-10-22T16:29:24Z"
      status: "True"
      mgs: "rate limiting available"
      type: Ready

[maleck13]

@rahulanand16nov @eguzki any thoughts on something like the above

[maleck13]

To get a better view of the overall status, we have also identified that we need some improvements to the RateLimit resource and limitador. We can follow on with tasks to help us get a deeper insight into limitador and WASMPlugin etc
istio/istio#39193

[alexsnaps]

See Kuadrant/architecture#38

[eguzki]

One rate limit policy may be affecting multiple gateways targeting a route with multiple parent gateways. The WasmPlugin is per gateway basis.

[eguzki]

To take into account as well that depending on the gateways, routes and policies, as well as route selectors, a wasmplugin may not be created because there is nothing to rate limit. So, there are scenarios, where reconciliation is done successfully, but the policy is indeed ineffective. If this is a spec configuration mistake (for example wrong route selectors), the status conditions should shout out: "ey, there is nothing I can do, it is your fault and rate limiting will not happen"

[alexsnaps]

Closing this in favor of the RFC one...