feat: remove the creation of cronjobs in cleanup controller

[MariamFahmy98]

Explanation

This PR removes the usage of cronjob in the cleanup controller. Instead the policy is requeued with a delay.
The reconciliation function do the following:

1. If it's the first time to execute the cleanup policy:
   • calculate the next execution time based on the policy creation time.
   • calculate the delay between now and the next execution time.
   • re-queue the policy with the delay.
2. If it isn't the first time to execute the cleanup policy:
   • check if this is the time to do the cleanup process, if so:
     • do the cleanup process.
     • update the cleanup policy status with the execution time.
     • calculate the next execution time.
     • calculate the delay between now and the next execution time.
     • re-queue the policy with the delay.
   • if it isn't the time to do the cleanup, then:
     • calculate the delay between now and the expected execution time.
     • re-queue the policy with the delay.

In case spec.schedule is modified, then the next execution time is re-calculated with the new value of spec.schedule.

Fixes #8306
Fixes #8073

[chipzoller]

Does this take into consideration if the policy is updated to increase or decrease the time between the next reconciliation?

[eddycharly]

Why not store lastExecutionTime ?

[MariamFahmy98]

Why not store lastExecutionTime ?

If a new cleanup policy is created, then the policy needs to be executed at least once to have status.lastExecutionTime set so how to know the time to do the cleanup process for the 1st time?

Does this take into consideration if the policy is updated to increase or decrease the time between the next reconciliation?

No. In case spec.schedule is modified, the next reconciliation happens depending on status.nextExecutionTime which is already calculated depending on the old value of spec.schedule before the policy itself modified. After the next reconciliation is executed, the status.nextExecutionTime will be calculated based on the new value of spec.schedule

[eddycharly]

If a new cleanup policy is created, then the policy needs to be executed at least once to have status.lastExecutionTime set so how to know the time to do the cleanup process for the 1st time?

Take creationTime in this case ;)

[MariamFahmy98]

@chipzoller - Now, if spec.schedule is modified then the policy is re-queued with a delay equals to the new value + the last execution time.

[codecov]

Codecov Report

Merging #8526 (2bebbf8) into main (45a45b6) will decrease coverage by 0.14%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main    #8526      +/-   ##
==========================================
- Coverage   35.78%   35.65%   -0.14%     
==========================================
  Files         313      313              
  Lines       25049    25143      +94     
==========================================
  Hits         8965     8965              
- Misses      15194    15288      +94     
  Partials      890      890              

Files	Coverage Δ
api/kyverno/v2alpha1/cleanup_policy_types.go	45.20% <ø> (ø)
pkg/controllers/cleanup/condition.go	17.85% <ø> (ø)
api/kyverno/v2alpha1/zz_generated.deepcopy.go	0.00% <0.00%> (ø)
pkg/controllers/cleanup/controller.go	0.00% <0.00%> (ø)

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

[eddycharly]

The logic to get last execution time should be part of the interface imho.

[eddycharly]

/cherry-pick release-1.11