Heidi Eckhart wrote:
Jay Gagnon wrote:
# HG changeset patch # User Jay Gagnon <grendel@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@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