Re: [Libvirt-cim] [PATCH 0 of 9] Reorganized association provider registration
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(a)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