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(a)linux.vnet.ibm.com