Currently only tracing and monitoring give insights on Kubewarden policy state.
Policies have status (unscheduled, pending, active). But that that if policies are already deployed and active in a policy-server, scheduling a change of them (for rules, settings, etc), would not move back to pending and again to active. Since the old instantiated policy is still reachable via the webhook and the old policy-server pod. This can be confusing in UI and for new users.
Acceptance criteria
Emit Kubernetes events when policies change the status (to unscheduleded, pending, to active).
Consider emitting a specific event when a policy is already active yet is being updated (with new rules, settings, etc).
This comes from https://www.youtube.com/watch?v=KbKQu3AqhBY.
Currently only tracing and monitoring give insights on Kubewarden policy state.
Policies have status (unscheduled, pending, active). But that that if policies are already deployed and active in a policy-server, scheduling a change of them (for rules, settings, etc), would not move back to pending and again to active. Since the old instantiated policy is still reachable via the webhook and the old policy-server pod. This can be confusing in UI and for new users.
Acceptance criteria