[Libvirt-cim] [PATCH 0 of 2] Enable ECTP's multiple namespace capability

[Kaitlin Rupert]

Heidi Eckhart wrote:
> Kaitlin Rupert wrote:
>> I hit a minor issue with Pegasus.  After a postinstall, I see the 
>> following:
>>
>> Warning: the instance already exists.
>> In this implementation, that means it cannot be changed.
>> Warning: the instance already exists.
>> In this implementation, that means it cannot be changed.
>>
> Yes, I'm aware of this issue. The reason for this message is following. 
> To register a provider for Pegasus it is necessary to create the 
> following instances (that are configured by the <classname>.registration 
> file) in Pegasus' root/PG_InterOp namespace.
> 
> This is the content of the ElementConformsToProfile.registration file:
>    Xen_ElementConformsToProfile root/virt Virt_ElementConformsToProfile 
> Virt_ElementConformsToProfile  association
>    Xen_ElementConformsToProfile root/interop 
> Virt_ElementConformsToProfile Virt_ElementConformsToProfile  association
>    KVM_ElementConformsToProfile root/virt Virt_ElementConformsToProfile 
> Virt_ElementConformsToProfile  association
>    KVM_ElementConformsToProfile root/interop 
> Virt_ElementConformsToProfile Virt_ElementConformsToProfile  association
> 
> that is translated to:
> * one instance of PG_ProviderModule registering the provider's module 
> name as defined by STDA_AssocMIStub() ... Virt_ElementConformsToProfile
> * one instance of PG_Provider registering the name of the provider 
> library ... Virt_ElementConformsToProfile
> * one instance of PG_ProviderCapabilities per classname registration
>    - one instance of PG_ProviderCapabilities ... 
> Xen_ElementConformsToProfile-1 (root/virt)
>    - one instance of PG_ProviderCapabilities ... 
> Xen_ElementConformsToProfile-2 (root/interop)
>    - one instance of PG_ProviderCapabilities ... 
> KVM_ElementConformsToProfile-3 (root/virt)
>    - one instance of PG_ProviderCapabilities ... 
> KVM_ElementConformsToProfile-4 (root/interop)
> 
> This is done each time when running provider_register - in our case 
> twice ... root/virt and root/interop (see Makefile.am postinstall step). 
> The provider_register script does now skip all PG_ProviderCapabilities 
> instances, who's namespace is not the same as the one given by the 
> caller of provider_register. But with the current setup of 
> provider_register it would cause a disproportional effort to make the 
> second run (root/interop) aware of that the first run (root/virt) has 
> already registered PG_ProviderModule and PG_Provider. As the second 
> registration try does only cause the warnings above but no corruption, I 
> decided to live with them (for now).
> FYI ... sfcb's registration does not run into this issue :).
> 

Thanks for the excellent explanation Heidi.  This makes sense to me. 
And I agree, it seems like a considerable effort to change the 
provider_register script.

+1
-- 
Kaitlin Rupert
IBM Linux Technology Center
kaitlin at linux.vnet.ibm.com