[Libvirt-cim] [PATCH] [RFC] Changes required to work with new std_indication. The trigger changes were very light, which was nice

[Jay Gagnon]

Heidi Eckhart wrote:
> Jay Gagnon wrote:
>> # HG changeset patch
>> # User Jay Gagnon <grendel at linux.vnet.ibm.com>
>> # Date 1202420324 18000
>> # Node ID a82dd87a3830eadda678b88bf4bfcfd4f8cb1ca4
>> # Parent  c7dd4a8358a187a3469c3d8a177950625898a227
>> [RFC] Changes required to work with new std_indication.  The trigger 
>> changes were very light, which was nice.
>>
>> Signed-off-by: Jay Gagnon <grendel at linux.vnet.ibm.com>
>>
>> diff -r c7dd4a8358a1 -r a82dd87a3830 src/Virt_ComputerSystemIndication.c
>> --- a/src/Virt_ComputerSystemIndication.c    Wed Feb 06 07:00:00 2008 
>> -0800
>> +++ b/src/Virt_ComputerSystemIndication.c    Thu Feb 07 16:38:44 2008 
>> -0500
>> @@ -488,7 +488,8 @@ STDI_IndicationMIStub(,
>>                        Virt_ComputerSystemIndication,
>>                        _BROKER,
>>                        libvirt_cim_init(), -                      &csi);
>> +                      &csi,
>> +                      NULL);
>>
>>  /*
>>   * Local Variables:
>>   
> I'm interested in the other changes that are necessary to the 
> CSIndication provider to make use of the std_indication reorg - also 
> make use of the states and not setting it to NULL ;).
Haha yea it's just set to NULL here in the interest of using the minimal 
amount of change to not break it.  When I have everything else in place 
I'll make sure CSIndication fully utilizes the new code.
>> diff -r c7dd4a8358a1 -r a82dd87a3830 
>> src/Virt_ComputerSystemMigrationIndication.c
>> --- a/src/Virt_ComputerSystemMigrationIndication.c    Wed Feb 06 
>> 07:00:00 2008 -0800
>> +++ b/src/Virt_ComputerSystemMigrationIndication.c    Thu Feb 07 
>> 16:38:44 2008 -0500
>>   
> If I got this right, then the MigrationIndication provider is 
> currently only switching the migrate.filter_activate and 
> migrate.enabled values. Potentially it could deliver an indication (by 
> the default_raise function), but it can not as the trigger_fn is not 
> implemented and so nothing is monitored, right ?
That is correct, and that's actually the intended behavior.  Attempting 
to monitor out of band migrations is not a problem I'm terribly 
interested in solving at the moment, and the raise functionality is tied 
into by VSMigrationService in a previous patch.  The end result is that 
whenever our providers are asked to do a migration task, 
VSMigrationService uses MigrationIndication's raise call to send the 
indication.
>
> Well, in sum - I like the approach :) - but I would even go farther. I 
> think its possible to write one indication engine (that would become 
> part of libcmpiutil) that handles all the CIM_InstModification, 
> CIM_InstCreation and CIM_InstDeletion indications at once. This engine 
> would be a large part of the CSIndication provider and maybe only the 
> compare functions (dom_in_list, dom_changed) need to stay provider 
> specific. But that's a guess at the moment and is worth to be 
> evaluated (now I hope that you volunteer for this job ;) ).
>
Yes, this will definitely go further. This is basically phase one of three.

-- 

-Jay