Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emit events from Metacontroller #7

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

Comments

@enisoc
Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Contributor

commented Jul 19, 2018

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

@nikhilk

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
6 participants
You can’t perform that action at this time.