I would like to collect potential use cases from mom, hosted engine and others so we could design the api to enable them
Both MOM and hosted engine need to monitor VM state (up, down) and migration status (finished), so at least that is needed.
Do we have any use cases to subscribe to additional topic(s) during life time of a client or subscription during instantiation is good enough.
Subscribing during startup is enough for those two if it means it will get the updates even for VMs that will appear later (this is needed for MOM). But why limit that?
As part of the work I would like to see whether there is a need to have global event topic or have name convention and use more granular queues.
Having a separate queue might allow us to use more granular event handlers and avoid type detection in the code. It might allow to to listen only for status updates of a certain VM (hosted engine) in the more complicated example (ex: /event/vmstatus/HostedEngine) or all of them (/event/vmstatus/*) in case of MOM. Martin On Mon, Jan 2, 2017 at 11:02 AM, Piotr Kliczewski <piotr.kliczewski@gmail.com> wrote:
All,
Some time ago during discussion we noticed that we are missing ability to send/receive events from vdsm client [1]. Initially we thought that having [2] would be enough to support notification between engine and vdsm. Now we know we need it for [1].
I would like to collect potential use cases from mom, hosted engine and others so we could design the api to enable them.
As part of the work I would like to see whether there is a need to have global event topic or have name convention and use more granular queues.
Do we have any use cases to subscribe to additional topic(s) during life time of a client or subscription during instantiation is good enough.
Thanks, Piotr
[1] https://github.com/oVirt/vdsm/blob/master/lib/vdsmclient/client.py [2] https://github.com/oVirt/vdsm/blob/master/vdsm/clientIF.py#L149