Re: [ovirt-devel] [VDSM] Notification in vdsm client
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(a)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