[ovirt-devel] Reference implementation of events

[Vinzenz Feenstra]

On 02/09/2015 04:23 PM, 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.
Just a correction here: We're currently polling the stats every 15 seconds.
What the wiki page showed was an attempt to apply classification to the
data returned by getAllVmStats to avoid polling data that does not change
that often.

In an event based system the content of the there [2] proposed verbs:
'getVmStatus', 'getVmConfInfo' and 'getVmGuestDetails' could be potentially
changed to events.

The contents of the proposed 'getAllVmRuntimeStats' verb was under the 
consideration
of the periodic polling (~3seconds)  approach, which does not fit 
anymore in an
event based system.
One thing is clear though, this data changes quite frequently and is 
used by the engine
(ignoring the hashes which were part of the proposal)
The fields cpuSys, cpuUser, memUsage are needed for the frontend and 
must be distributed
frequently.
The value of 'elapsedTime' and 'statsAge' are changing constantly 
basically with every request,
however I am not sure about the value to the engine. This is a point to 
discuss.

The VM 'status' should, in normal/expected scenarios, change rarely, 
however when it does,
in most, but necessary not all cases (to be determined), the engine must 
know immediately.
(This is why it is polled every 3 seconds)

The 'hashes.config' value, probably gets kind of irrelevant on an event 
based system, since we would
send changed devices / configuration as the aforementioned deltas in an 
event.
But I might be wrong about that.

The 'getAllVmDeviceStats' data is something that should be periodically, 
kind of, requested.
Part of the data is used by SLA, other parts are used by the engine to 
display it, and then parts of it,
might be used by the DWH. How we are going about those things, is also 
open for discussion.

I hope I haven't left out anything so far. I just wanted to give a bit 
of an idea how the page should be considered
in relation to the new message based implementations.

>
> 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?
>
> Thanks,
> Piotr
>
> [1] http://gerrit.ovirt.org/#/c/37488/
> [2] http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval


-- 
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com