In a test Microk8s environment, I was able to deploy this charm and have it, upon deletion of existing pods, apply the specified affinity rules to new pods.
However, the namespace-node-affinity-pod-webhook-* pod cannot be deleted in the same way, for likely obvious reasons - I suspect it is the pod which is performing the work of injecting affinity rules, and cannot apply them to itself.
Is there some way that we could apply the same affinity rules to the webhook pod itself, e.g. through the operator pod? (I haven't written this type of Kubernetes charm, but it seems like the operator pod spawns the webhook pod? In which case, perhaps the rules need to be injected by the operator pod when spwaning the webhook pod? Just an idea.)
To Reproduce
Deploy a model with this charm.
Set the settings_yaml config to point at the same model where this charm is deployed.
Delete the namespace-node-affinity-0 pod. (It will receive the modified affinity rules.)
Delete the namespace-node-affinity-pod-webhook-* pod. (It will not receive the modified affinity rules.)
Bug Description
In a test Microk8s environment, I was able to deploy this charm and have it, upon deletion of existing pods, apply the specified affinity rules to new pods.
However, the namespace-node-affinity-pod-webhook-* pod cannot be deleted in the same way, for likely obvious reasons - I suspect it is the pod which is performing the work of injecting affinity rules, and cannot apply them to itself.
Is there some way that we could apply the same affinity rules to the webhook pod itself, e.g. through the operator pod? (I haven't written this type of Kubernetes charm, but it seems like the operator pod spawns the webhook pod? In which case, perhaps the rules need to be injected by the operator pod when spwaning the webhook pod? Just an idea.)
To Reproduce
Environment
Juju controller: 2.9.43 K8s: Microk8s v1.28.7 namespace-node-affinity charm version: revision 18, latest/stable
Relevant Log Output
Additional Context
No response