On Mon, Jan 2, 2017 at 12:02 PM, 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].
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