Resources are pruned if using ApplySets

[uhthomas]

Expected behaviour

Kubernetes has introduced ApplySets, an improvement to server side apply and pruning.

https://kubernetes.io/blog/2023/05/09/introducing-kubectl-applyset-pruning/

ApplySets work by applying labels to objects it manages.

{
  "labels": {
      "app.kubernetes.io/component": "redis",
      "app.kubernetes.io/managed-by": "redis-operator",
      "app.kubernetes.io/name": "redis",
      "app.kubernetes.io/part-of": "redis-failover",
      "applyset.kubernetes.io/part-of": "applyset-xjZyH1FmMYtP-oSkfLUgubxDYIbsrD-IuDRLmezicIo-v1",
      "redisfailovers-role": "slave",
      "redisfailovers.databases.spotahome.com/name": "redis"
  }
}

The applyset label should not be inherited, or else the created resources are pruned.

Actual behaviour

service/rfr-redis pruned
service/rfs-redis pruned
deployment.apps/rfs-redis pruned
poddisruptionbudget.policy/rfr-redis pruned
poddisruptionbudget.policy/rfs-redis pruned
statefulset.apps/rfr-redis pruned
configmap/rfr-readiness-redis pruned
configmap/rfr-redis pruned
configmap/rfr-s-redis pruned
configmap/rfs-redis pruned

Steps to reproduce the behaviour

Create a RedisFailover object with KUBECTL_APPLYSET=true kubectl apply --server-side --applyset=some-apply-set --prune -f -. Wait for the resources to be created, and then observe they are pruned when the original custom resource is applied again.

Environment

How are the pieces configured?

• Redis Operator version 1.2.4
• Kubernetes version 1.27.1
• Kubernetes configuration used (eg: Is RBAC active?) Server-Side Apply, ApplySets.

Logs

N/A

[uhthomas]

I recognise this behaviour is configurable with the LabelWhitelist field, though I would urge the authors to reconsider the default behaviour. I would expect that with the introduction of ApplySets, pruning will become more popular and label propagation should be opt-in rather than opt-out. Either that, or an exception should be made specifically for applyset labels.

[github-actions[bot]]

This issue is stale because it has been open for 45 days with no activity.

[uhthomas]

Closing an issue due to age isn't helpful for anyone.

[github-actions[bot]]

This issue is stale because it has been open for 45 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.