Emit Events for ClusterTriggerAuthentication

[zroubalik]

Signed-off-by: Zbynek Roubalik zroubali@redhat.com

Kubernetes Events haven't been emitted for ClusterTriggerAuthentication, adding a controller the sam way it is done for TriggerAuthentication. Should be enough for now

Checklist

• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• [N/A] Tests have been added
• [N/A] A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on Document k8s Events for ClusterTriggerAuthentication keda-docs#385
• Changelog has been updated

Fixes #1523

[coderanger]

I don't really understand why we would do this? Those events aren't really useful for anything? It doesn't hurt per se but this implies you're trying to use events instead of an audit webhook for logging/recording/announcing cluster data changes.

[tomkerkhove]

This can be useful outside of the scope of Kubernetes where you want to extend it or react in some other apps.
http://k8s-event-grid-bridge.io/

That's more a general remark, not for these events (although I see its value), but why not be open; maybe somebody does cool stuff with them!

[coderanger]

It is more code to maintain and some small amount of increased load on the cluster if you are creating and deleting objects a lot. And the audit webhook system provides that kind of info for every object type, and a lot more info too (who did it, for example).

[coderanger]

Not strongly against these but it feels like it is redundant with stuff K8s already provides better via other means :)

[zroubalik]

I can see your point, that these events aren't that imporant. But because we are already emitting the same events for the other objects, I think that we should have unified experience and this PR fixes that. The increased load and addition code is not that imho huge, we can think of this as a first spike to an additional related functionality.

[tomkerkhove]

Agreed, we can still make it an opt-out if we have the need?

[coderanger]

Probably not even worth that, the maintenance is the bigger thing and even that is minimal. If we end up doing this for a bunch of types, we could make a shared generic version instead. That said, I'm not 100% sure this works? I don't think objects get the reconcile on delete if there isn't a finalizer to handle?