Skip to content
This repository has been archived by the owner. It is now read-only.

Emit events from Metacontroller #7

Open
enisoc opened this issue Dec 28, 2017 · 8 comments
Open

Emit events from Metacontroller #7

enisoc opened this issue Dec 28, 2017 · 8 comments
Assignees
Milestone

Comments

@enisoc
Copy link

@enisoc enisoc commented Dec 28, 2017

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.

@enisoc enisoc added this to Ready in Metacontroller Dec 28, 2017
@yastij
Copy link

@yastij yastij commented Dec 31, 2017

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

@enisoc enisoc added this to the Alpha milestone Jan 16, 2018
@enisoc
Copy link
Author

@enisoc enisoc commented Jan 16, 2018

@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
Copy link
Member

@nikhilk nikhilk commented Jul 16, 2018

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
Copy link
Author

@enisoc enisoc commented Jul 18, 2018

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
Copy link
Contributor

@rlguarino rlguarino commented Jul 19, 2018

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

@nikhilk
Copy link
Member

@nikhilk nikhilk commented Jul 19, 2018

+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
Copy link

@grzesuav grzesuav commented Apr 25, 2019

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
Copy link

@grzesuav grzesuav commented Jan 16, 2020

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Metacontroller
  
Ready
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants