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