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

[Dan Smith]

HE> Yes, for Pegasus, but not for sfcb - sfcb calls the association
HE> provider only once, with the client's assocClass
HE> (e.g. CIM_SystemDevice), while Pegasus manipulates assocClass to
HE> fit the subclass' association name (Xen_SystemDevice and
HE> KVM_SystemDevice) and calls the provider for each subclass.

Ah, okay.  Hmm, that's unfortunate that they behave so differently.

So, if you resolve the association with an assocClass of CIM_Foo on
sfcb, the provider handler actually sees CIM_Foo as the assocClass,
per my testing just now.  So we need to make sure that we don't use
the assocClass (or resultClass) as the target of a
connect_by_classname().  Might be obvious, but I just wanted to make
it explicit.

HE> Therefore I added match_hypervisor_prefix() function, which
HE> compares the given ref prefix with the client requested assocClass
HE> and resultClass prefix.

Okay, looking at that now, it makes more sense.  I was confusing
match_hypervisor_prefix() with match_pn_to_cn().

HE> Right. And I also know, that the ASSOC_MATCH solution was developed to
HE> deal with Pegasus' special behavior to handle association requests.

Well, I didn't know it was special to Pegasus at the time :)

I thought we were seeing the same behavior out of sfcb as well.

HE> As mentioned above, sfcb is calling the Virt_ providers only
HE> once. We could now start a discussion which solution is the right
HE> one, but as we will not be the ones who decide on this, 

Personally, Pegasus' behavior makes more logical sense to me, but the
sfcb case does seem more efficient.

HE> I would like to implement a solutions, that also makes use of the
HE> optimized sfcb behavior, where the provider is called only once.

Agreed.

HE> My suggestion now is, to replace ASSOC_MATCH by
HE> match_hypervisor_prefix() and register Virt_ providers instead of
HE> Xen_/KVM_ for each subclass. The advantage can not be seen with
HE> Pegasus, as Pegasus will still call the provider for each subclass
HE> with the manipulated assocClass. But for sfcb we get rid of an
HE> unnecessary provider call. What do you think ?

Yes, and it also eliminates the need to add an additional registration
for each prefix we support, which is a good thing.

Thanks Heidi!

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms at us.ibm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvirt-cim/attachments/20071204/7a8d9033/attachment.sig>