5 a.m.
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