New RLP CRD version

[eguzki]

From RFC 0001

Group	Version	Kind
kuadrant.io	v2beta1	RateLimitPolicy

Example with all fields:

apiVersion: kuadrant.io/v2beta1
kind: RateLimitPolicy
metadata: {}
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: <HTTPROUTE-NAME>
  limits:
    <limit-name>:
      routeSelectors:           
      - hostnames:
         - "*example.com"
        matches:                # []HTTPRouteMatch
        - path:                      # HTTPPathMatch 
            type: PathPrefix
            value: "/toys"
          method: GET          # HTTPMethod 
          headers:                # []HTTPHeaderMatch 
          - type: Exact
            name: "X-Canary"
            value: "1"
          queryParams:      # []HTTPQueryParamMatch 
          - type: Exact
            name: "q"
            value: "1"
      rates:
      - limit: 50
        duration: 1
        unit: minute
      counters:
      - auth.identity.username
      - context.request.http.path
      when:
      - selector: auth.identity.group
        operator: neq
        value: admin

[guicassolato]

In RFC 0001, we exemplified hostnames at the same level as matches. I think the idea was that matches could be typed as or identical to GWAPI's []HTTPRouteMatch.

I have nothing against bringing hostnames as new field of brought inside of matches, side-by-side with the other fields inherited from GWAPI. However, in that case, we probably don't need the matches level at all. routeSelectors could of type []Selector, where:

type Selector struct {
  Hostnames:   []Hostname            `json:"hostnames,omitempty"`
  Path:        []HTTPPathMatch       `json:"paths,omitempty"`
  Method:      HTTPMethod            `json:"method,omitempty"`
  Headers:     []HTTPHeaderMatch     `json:"headers,omitempty"`
  QueryParams: []HTTPQueryParamMatch `json:"queryParams,omitempty"`
}

Any advantage on keeping matches []HTTPRouteMatch or let's go with the custom Selector type above?

[eguzki]

. However, in that case, we probably don't need th

That sounds good, because I also believe that routeSelectors matches should be the type of []HTTPRouteMatch

[guicassolato]

I also believe that routeSelectors should be the type of []HTTPRouteMatch

But it wouldn't, right? The two options pitched are:

1. Using HTTPRouteMatch (like in the RFC):

type RouteSelector struct {
  Hostnames []Hostname
  Matches   []HTTPRouteMatch
}

2. Without HTTPRouteMatch:

type RouteSelector struct {
  Hostnames:   []Hostname            `json:"hostnames,omitempty"`
  Path:        []HTTPPathMatch       `json:"paths,omitempty"`
  Method:      HTTPMethod            `json:"method,omitempty"`
  Headers:     []HTTPHeaderMatch     `json:"headers,omitempty"`
  QueryParams: []HTTPQueryParamMatch `json:"queryParams,omitempty"`
}

[eguzki]

Correct, updated previous comment

[eguzki]

Do we want v2beta1 or v1beta2?

In RFC 0001 v2beta1 is specified. But as we are skipping v1 it seems a long hop IMO.