feat: resource requirements

[KevFan]

Description

• Use default and allow specifying resource requirements for limitador pod
• Use ginkgo v2 as v1 is deprecated
• Increase unit test coverage of /api

Closes: #74

Verification

Functionality is generally tested by the included tests already but you can run through the following for a more thorough verification:

• Checkout this branch
• Deploy local cluster and build

make local-setup

• Deploy limitador cr with no resource requirements

kubectl apply -f config/samples/limitador_v1alpha1_limitador.yaml

• Verify default limits are set

kubectl get deployments limitador-sample -o json | jq '.spec.template.spec.containers[0].resources'

• Patch Limitatdor CR with resource limits

kubectl apply -f -<<EOF                                          
apiVersion: limitador.kuadrant.io/v1alpha1
kind: Limitador
metadata:
  name: limitador-sample
spec:
  listener:
    http:
      port: 8080
    grpc:
      port: 8081
  limits:
    - conditions: ["get_toy == 'yes'"]
      max_value: 2
      namespace: toystore-app
      seconds: 30
      variables: []
  resourceRequirements:
    limits:
      cpu: 200m
      memory: 400Mi
    requests:
      cpu: 101m
      memory: 201Mi         
EOF

• Verify resource limits specified are set

kubectl get deployments limitador-sample -o json | jq '.spec.template.spec.containers[0].resources'

• Patch CR with empty resource requirements (i.e. no limits)

kubectl apply -f -<<EOF                                                                           
apiVersion: limitador.kuadrant.io/v1alpha1
kind: Limitador         
metadata:               
  name: limitador-sample
spec:      
  listener:     
    http:       
      port: 8080
    grpc:       
      port: 8081                      
  limits:                             
    - conditions: ["get_toy == 'yes'"]
      max_value: 2           
      namespace: toystore-app
      seconds: 30      
      variables: []    
  resourceRequirements: {}
EOF

• Verify resource limits are empty

kubectl get deployments limitador-sample -o json | jq '.spec.template.spec.containers[0].resources'

• Patch CR to set resource requirements back to nil

kubectl apply -f -<<EOF                                                                           
apiVersion: limitador.kuadrant.io/v1alpha1
kind: Limitador         
metadata:               
  name: limitador-sample
spec:      
  listener:     
    http:       
      port: 8080
    grpc:       
      port: 8081                      
  limits:                             
    - conditions: ["get_toy == 'yes'"]
      max_value: 2           
      namespace: toystore-app
      seconds: 30      
      variables: []    
EOF

• Verifiy default limits are applied

kubectl get deployments limitador-sample -o json | jq '.spec.template.spec.containers[0].resources'

[codecov-commenter]

Codecov Report

Merging #83 (12485ea) into main (e110bb7) will increase coverage by 6.56%.
Report is 2 commits behind head on main.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #83      +/-   ##
==========================================
+ Coverage   43.31%   49.87%   +6.56%     
==========================================
  Files          11       12       +1     
  Lines         718      812      +94     
==========================================
+ Hits          311      405      +94     
  Misses        369      369              
  Partials       38       38              

Flag	Coverage Δ
unit	49.87% <100.00%> (+6.56%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed	Coverage Δ
api/v1alpha1/limitador_types.go	100.00% <100.00%> (ø)
controllers/limitador_controller.go	42.13% <100.00%> (+0.65%)	⬆️
pkg/limitador/k8s_objects.go	67.87% <100.00%> (+0.19%)	⬆️
pkg/reconcilers/deployment.go	24.24% <100.00%> (+24.24%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[KevFan]

Based on #74

[Boomatang]

Most of this looks good to me, there is a few questions in the comments.

On the point of making the assumption that container will be the first in the list is a concern. I have tried adding other containers to the deployment and the operator allows it to happen. When the extra container is the first in the list the operator rewrites the configuration to what we expect the configuration to be. It does not change the name of the container and leaves the old container there. If the extra container is added in the second position on the list the operator will leave the configuration on changed. This is possible a large issue and effects more than just this PR.

[Boomatang]

If I understand how Kuadrant.io is working, this file will be included in the documentation. My concern is the Limitador v1alpha1 API reference link will be a broken link on the site. Do you know if this is the case.

[KevFan]

No, I don't know will this be the case

[alexsnaps]

These links used to work fine... and should still in the new website, but I haven't checked explicitly. Tho I know authorino uses relative links like these a lot, and these were fine on docs.kuadrant.io

[Boomatang]

I have noticed we don't document the API. Is this the best place of the resource requirements or should there be a more targeted API documentation?

[KevFan]

I'm not sure tbh, I'm just matching https://github.com/Kuadrant/limitador-operator/blob/main/doc/storage.md which documents Storage seperately 🤷

[alexsnaps]

Are the (authorino|limitador)-operator docs on the website? quickly looking I couldn't find them 🤔

[alexsnaps]

here

[KevFan]

Rebased with main to resolve conflict

[eguzki]

LGTM
good job

[KevFan]

Rebased with main to resolve conflict again