On 09/02/15 17:23, Piotr Kliczewski wrote:
Hi,
As you may know I currently work on event infrastructure which will
let vdsm push information to the engine. I already pushed some drafts
providing event functionality and started to think which part of
engine <-> vdsm interaction could be changed to events. The goal is to
build usable api for it as well as provide example how to migrate
other parts of code to events.
Initially we started to look at VM.getStats [1] but we still want to
have Host.getAllVmStats run by quartz job. I had a chat with Vinzenz
about the structure and frequency of data change for VM.getStats and
it seems that the data changes ~2s so this verb is not the best choice
to send events with deltas containing the change since we are polling
every 3s for the information.
We started to explore which data generated by vdsm/guest agent could
be sent as events and he pointed me to [2].
I would like to trigger discussion about how to dived data to maximize
benefits of sending events with deltas and for some parts of data keep
polling functionality as it is now.
Do you have any suggestion which verb we could safely use as reference
implementation for events?
I'm not sure what you mean by "safely", but a good candidate (in terms
of both low frequency of changes and value of triggered events) would be
getVdsCaps. Especially if only deltas are sent.
For example, we'd love get relevant data from vdsm whenever a network
interface's IP address changes (an event which phoracek is currently
working on monitoring).
That's one example I know from networking, but maybe such examples exist
where the monitoring is already implemented and ready to be tested via
event triggering.