[Vesper-users] another commit made on sf.net

[Vigneswaran R <vi...@at...>]

Dear Kim-san,

We have made another commit to sf.net git repository which adds a patch 
to Vesper-0.0.2, in addition to some changes to our code.

Totally, we have created two patches. You can find them under,

     $(PATH_TO_CIMHA)/cimha_src/patches

Both the patches are independent and no common files will be affected. 
Currently, the cimha components are based on the assumption that the 
patch *vesper_struct_probedata-0.0.2.patch is applied* to Vesper-0.0.2. 
The other patch can be ignored (may be I will remove it from the 
repository eventually, if it is not needed).

Hereby, I describe about both the patches for completeness. Please 
review them and give us your feedback.

Patch #1: vesper_wait_events-0.0.2.patch  (can be ignored later)

change #1: removal of break statement from the end of the for loop in 
vsp_wait_events function.

This change makes the function to keep listening to the RA socket. This 
helps us to collect probe output continuously.

change #2: writing back the event handler's return value to the RA socket.

RA socket will be used by Vesper as well as Cimha. The vsp-appd writes 
probe output to the RA socket. In such case, the event handler's return 
value is of no importance.

In case of Cimha, grab probe utility (which invokes vsp_wait_events, and 
defines the event handler) uses RA socket for communicating with its 
client (Heartbeat) to provide the kernel helath assessed by KE based on 
the collected probe output. In such case, the event handler's return 
value is the KE's return value.

advantages: this patch enable us to collect probe output continuously 
and use RA socket to communicate with clients (in both directions).

disadvantages: this patch is not sufficient to get additional probe 
information like guest id and probe name which gave the output.

Patch #2: vesper_struct_probedata-0.0.2.patch

Objective: get more information about the probe output

To get more information about the probe output, we created a structure 
called probe_data in vsp-lib.h which has guest id, probe path and probe 
output in it. This structure will be written into the RA socket by 
vsp-appd instead of only probe output.

Changes to Cimha in this commit:
--------------------------------
We made cimha agent as the single entity to collect the probe output 
from vsp-appd and to distribute to all the other Cimha components 
(whoever in need). It creates and listens to the RA socket directly (not 
using vsp_wait_events). Whenever there is some data available on RA 
socket, it collects and writes it into another predefined socket called 
probe data socket (created by grab probe utility - a cimha component), 
if available.

TODO: In addition to the above, cimha agent will buffer the latest (few) 
output(s) from all the probes which can be then be accessed by Cimha GUI 
for displaying purposes.

Your comments are welcome. Thank you.

Best Regards,
Vignesh


金　成昊 wrote:
> Dear Vigneswaran-san,
> 
> Thank you very much for your commit.
> 
> Regards,
> Kim
> 
>> Dear Kim-san,
>>
>> We have committed our CIMHA code to sf.net git repository. Please pull
>> it and test it. Git repository information is available under
>> <http://sourceforge.net/projects/cimha/develop>.
>>
>> In the cimha-convirt directory, all the *cimha* components are moved
>> inside cimha_src subdirectory.
>>
>> Additions
>> ---------
>>
>> 1. KE as a daemon
>> 2. TL library
>> 3. probes (as of now, only probes/mem_usage.c probe is usable. we will
>> commit some more probes soon)
>> 4. a patch to libvsp (vsp_wait_events) to keep on collecting probe output
>> 5. utilities to interact with vsp-appd to collect probe output and to
>> communicate with KE for taking decision. the grab_probe_output utility
>> uses "crm_resource" command to initiate migration based on events from
>> probes like apache_monitor (event driven).
>>
>> Please see the README files for more details. Install the components
>> by following the instructions in them.
>>
>> Test Environment
>> ----------------
>> 1. One VM was running on each active and standby node
>> 2. Vesper was configured (drivers loaded etc.)
>> 3. vsp-appd was started
>> 4. Cimha components cimha agent, cmh_ke were started
>> 5. Cimha component ke_ra (OCF script) was configured to heartbeat as a
>> resource which starts the other utilities to communicate with vsp-appd
>> and KE
>> 6. Apache service inside VM was configured as a resource to Heartbeat
>> through cmh_ra
>> 7. a modified version of apache_monitor probe was inserted into guest
>> using cmh-tool (modified the output format, see the probes/README file)
>> 8. mem_usage probe was inserted into guest (outputs % of memory usage
>> periodically)
>>
>> Testing
>> -------
>> 1. killing of apache process inside guest immediately triggers
>> migration of resources (type: event driven)
>> 2. increasing the memory usage beyond the threshold (95%) specified in
>> the KE's rules_file also caused the migration (type: polling)
>>
>> We have given detailed information in the README files for all the
>> components. Please go through them.
>>
>> TODOs
>> -----
>> 1. Maintaining the inserted probes information in a file (on a shared
>> disk) so that it can be inserted into the VM in the standby node, on
>> migration.
>> 2. Writing probes and KE rules to improve the KE rulebase.
>>
>> If you have any doubts, please let us know.
>>
>>
>> Regards,
>> vignesh
>>
> 
>