[VDSM] Notification in vdsm client
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
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
On Mon, Jan 2, 2017 at 12:02 PM, 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].
Why do you need events for the vdsm-client command? can you describe the use case?
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.
In the future we may have separate process for each storage domain, or each storage type. These processes would monitor storage health and post storage health notifications. Virt process would like to subscribe to storage domain notifications when starting a vm with disks on this domain and unsubscribe when stopping the last vm with disks on this domain. Virt would need to resume paused vms based on storage health events. In the same time engine would like to get the same events so we can handle non-functional storage domains and display alerts in the UI.
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.
I think we need a way to subscribe and unsubscribe any time, and also allow creation of notification queues any time. For example, when starting a new storage domain or storage driver type, we can create the queue for this storage domains events. Existing subscribers that want all storage domain events will get the new notifications. Nir
participants (3)
-
Martin Sivak -
Nir Soffer -
Piotr Kliczewski