Emit events from Metacontroller

[enisoc]

As Metacontroller attempts to act on behalf of a CompositeController, for example, it should emit events on the parent object as appropriate. We should look at what events built-in controllers emit as a starting point.

[yastij]

@enisoc - we might want to wait until this event design proposal is merged, otherwise we'll have to rewrite events, WDYT ?

[enisoc]

@yastij In my opinion, events will be an important debugging tool for anyone developing a controller with Metacontroller. I think we should go ahead and use the existing events API, so we don't have to wait until the new events proposal is merged and fully implemented before we can provide this.

I imagine our use of the events API will be fairly simple -- a small number of locations that emit events, whose content may be influenced by webhook responses -- so it shouldn't be too involved to switch to the new API when it's ready.

With that said, we should definitely take the new event design into account when deciding whether/how to allow webhooks to explicitly generate events, so that those webhooks don't need to change when we switch to the new events API. However, this tracker is only about events emitted directly by Metacontroller so I don't think it needs to wait.

[nikhilk]

Are there any specific events you had in mind?

I don't know if I am thinking of events in the way you intend in scope of this issue, but it would be useful to know when a CRD instance is being added/deleted -- to manage some off cluster state/side-effects associated with the resource. Or is there some other mechanism to use to address that (esp. delete, since add is can be approximated by the first time an object is seen in the sync hook).

Also, it seems like resyncPeriods could be manifested as a timer tick event on a resource, so its explicitly clear that its a cron event, rather than some other change-driven sync.

[enisoc]

I talked with @nikhilk face to face about this. Here are my thoughts for anyone following along:

This particular issue is only about emitting events in the sense of kubectl get events or the list of events shown by kubectl describe to help with human introspection/debugging. We can discuss "events" in the sense @nikhilk used above in #68 and #69.

[rlguarino]

Thanks for keeping these issues updated with the face to face conversations @enisoc

[nikhilk]

+1 thanks. And also good to understand the events feature as was originally intended here. Sorry for the bit of noise on this issue itself.

[grzesuav]

Hi, feature looks promising, is there any progres on that ? Or we need to wait for volunteers ? Any idea how it could be implemented ?

[grzesuav]

Several use cases :

• emits event when problem occurs in operator logic (so they are attached to parent resource and user can see them via kubectl describe)
• when operator is executing some external code (http request/db operations )it is particularly useful

I believe it is the easiest way to communicate to users what is happening