[Libvirt-cim] [PATCH 0 of 9] Reorganized association provider registration

[Heidi Eckhart]

Kaitlin Rupert wrote:
> Dan Smith wrote:
>> KR> Applying these patches didn't fix the dups for me (btw, thanks for
>> KR> finding the dups!).  I think the Virt_ provider still gets called
>> KR> twice.
>>
>> Yeah, with more testing, I still get dups as well.  Changing back to a
>> unified provider name doesn't change the fact that the CIMOM still
>> calls the provider once per registered class.  
Yes, for Pegasus, but not for sfcb - sfcb calls the association provider 
only once, with the client's assocClass (e.g. CIM_SystemDevice), while 
Pegasus manipulates assocClass to fit the subclass' association name 
(Xen_SystemDevice and KVM_SystemDevice) and calls the provider for each 
subclass.
>> The unified case
>> prevents us from having a key to filter on too.
Therefore I added match_hypervisor_prefix() function, which compares the 
given ref prefix with the client requested assocClass and resultClass 
prefix.
>>
>> My previous statement about connect_by_classname() is invalid too,
>> because we use the ref for connecting, which will be, for example,
>> Xen_Foo in both cases (for the KVM instance and the Xen instance of
>> the provider's registration).
Yes, we can not use the ref to figure out for which association the 
provider was called. :(
>>
>> So, I think the bottom line is:  We still need ASSOC_MATCH() and it is
>> the proper way to fix this problem for the associations that we
>> currently have without it.
>>
>> Right?
>>   
> Right..  ASSOC_MATCH() solves this problem.  There might be another 
> solution, but I'm not sure of one at the moment.
>
Right. And I also know, that the ASSOC_MATCH solution was developed to 
deal with Pegasus' special behavior to handle association requests. As 
mentioned above, sfcb is calling the Virt_ providers only once. We could 
now start a discussion which solution is the right one, but as we will 
not be the ones who decide on this, I would like to implement a 
solutions, that also makes use of the optimized sfcb behavior, where the 
provider is called only once.
My suggestion now is, to replace ASSOC_MATCH by 
match_hypervisor_prefix() and register Virt_ providers instead of 
Xen_/KVM_ for each subclass. The advantage can not be seen with Pegasus, 
as Pegasus will still call the provider for each subclass with the 
manipulated assocClass. But for sfcb we get rid of an unnecessary 
provider call. What do you think ?

But you both are right - the patch set is buggy and needs to be fixed in 
regard to ASSOC_MATCH. Thanks for making me aware of it. Will try to 
send out a fix as soon as possible.

-- 
Regards

Heidi Eckhart
Software Engineer
Linux Technology Center - Open Hypervisor

heidieck at linux.vnet.ibm.com

**************************************************
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294