During pruning the code is filtering objects with `CurrentUIDFilter`:
> // CurrentUIDFilter implements ValidationFilter interface to determine
// if an object should not be pruned (deleted) because it has recently
// been applied.
This must mean that the object has ended up being tracked in the inventory by more than one reference and the one that was flagged by the filter should be removed from the inventory. Otherwise, it gets stuck in the inventory indefinitely and during every invocation of prune it'll be logged as skipped.
A good example of this is `Ingress` kind existing in both groups `extensions` and `networking.k8s.io` in k8s 1.19 & 1.20. This means when you rename the apiGroup in your local yaml to the new recommended group, then the reference with the old group name gets permastuck in the inventory.
There was a bug where an error from an apply filter wasn't propagated to the applyFailed event, which leaded to printed events without error message set on them:
> {"group":"rbac.authorization.k8s.io","kind":"RoleBinding","name":"redacted","namespace":"redacted","status":"Failed","timestamp":"2022-12-21T12:43:46Z","type":"apply"}
The refactor to include `Apply` and `ApplyWithPrune` interface methods
in `Storage` caused a regression where status is not alway applied. This
commit ensures that the status is always applied.
This commit introduces 2 new Storage interface methods to enable clients
to implement their own logic for applying inventory objects to the live
cluster.
- Don't error when a delete returns NotFound.
This means the object was deleted asynchronously by another client
between the initial GET for task scheduling and the delete task itself.
Log a warning, because it's possible the deletion may have violated
dependency ordering.
- Update apply and delte task logs to only log errors if the verbosity
is greater than -v=4. This should help reduce duplicate log messages.
- Duplicate the 1,000 Deployment test, but use a 1m reconcile timeout in
a retry loop.
- This verifies that the applier and destroyer are re-entrant at scale.
- This matches previous StatusPoller behavior which would error
and exit if there was a 403 Forbidden error from the apiserver.
- Handle status error before synchronization with immediate exit
Kubernetes Prow Robot