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
On 02/09/2015 04:23 PM, Piotr Kliczewski wrote: 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