[PATCH 0 of 9] Reorganized association provider registration
The association provider was registered for each subclass with a different name. That caused duplicated instances as the same provider gets called twice, but has no chance to figure out for which registration. This patch set tries to fix it. Please review. Thanks. Based on: - #2 Fix (again) VSMCaps and ElementCap - Remove devid-style InstanceID support from ELEC and EC
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196683313 -3600 # Node ID 6dbbe2c148a7cc2ba74ffc9e3ddcf7acdc30042c # Parent 8140438a647cd53017d79b7036702fc053fe9e9c EAFP: Provider registered per subclass The provider was registered for each subclass with a different name. That caused duplicated instances as the same provider gets called twice, but has no chance to figure out for which registration. wbemain -ac CIM_ElementAllocatedFromPool 'http://localhost/root/virt:KVM_Memory.DeviceID="qemu1/mem",CreationClassName="KVM_Memory",SystemName="qemu1",SystemCreationClassName=""' localhost:5988/root/virt:KVM_MemoryPool.InstanceID="MemoryPool/0" localhost:5988/root/virt:KVM_MemoryPool.InstanceID="MemoryPool/0" Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 8140438a647c -r 6dbbe2c148a7 schema/ElementAllocatedFromPool.registration --- a/schema/ElementAllocatedFromPool.registration Fri Nov 30 17:21:33 2007 -0800 +++ b/schema/ElementAllocatedFromPool.registration Mon Dec 03 13:01:53 2007 +0100 @@ -1,4 +1,4 @@ # Copyright IBM Corp. 2007 # Classname Namespace ProviderName ProviderModule ProviderTypes -Xen_ElementAllocatedFromPool root/virt Xen_ElementAllocatedFromPoolProvider Virt_ElementAllocatedFromPool association -KVM_ElementAllocatedFromPool root/virt KVM_ElementAllocatedFromPoolProvider Virt_ElementAllocatedFromPool association +Xen_ElementAllocatedFromPool root/virt Virt_ElementAllocatedFromPoolProvider Virt_ElementAllocatedFromPool association +KVM_ElementAllocatedFromPool root/virt Virt_ElementAllocatedFromPoolProvider Virt_ElementAllocatedFromPool association diff -r 8140438a647c -r 6dbbe2c148a7 src/Virt_ElementAllocatedFromPool.c --- a/src/Virt_ElementAllocatedFromPool.c Fri Nov 30 17:21:33 2007 -0800 +++ b/src/Virt_ElementAllocatedFromPool.c Mon Dec 03 13:01:53 2007 +0100 @@ -326,8 +326,7 @@ static struct std_assoc *handlers[] = { NULL }; -STDA_AssocMIStub(, Xen_ElementAllocatedFromPoolProvider, _BROKER, libvirt_cim_init(), handlers); -STDA_AssocMIStub(, KVM_ElementAllocatedFromPoolProvider, _BROKER, libvirt_cim_init(), handlers); +STDA_AssocMIStub(, Virt_ElementAllocatedFromPoolProvider, _BROKER, libvirt_cim_init(), handlers); /* * Local Variables:
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196683550 -3600 # Node ID 97209a4aec46e659a9134dc28ac19c2f43b51c7c # Parent 6dbbe2c148a7cc2ba74ffc9e3ddcf7acdc30042c EC: Provider registered per subclass The provider was registered for each subclass with a different name. That caused duplicated instances as the same provider gets called twice, but has no chance to figure out for which registration. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 6dbbe2c148a7 -r 97209a4aec46 schema/ElementCapabilities.registration --- a/schema/ElementCapabilities.registration Mon Dec 03 13:01:53 2007 +0100 +++ b/schema/ElementCapabilities.registration Mon Dec 03 13:05:50 2007 +0100 @@ -1,4 +1,4 @@ # Copyright IBM Corp. 2007 # Classname Namespace ProviderName ProviderModule ProviderTypes -Xen_ElementCapabilities root/virt Xen_ElementCapabilitiesProvider Virt_ElementCapabilities association -KVM_ElementCapabilities root/virt KVM_ElementCapabilitiesProvider Virt_ElementCapabilities association +Xen_ElementCapabilities root/virt Virt_ElementCapabilitiesProvider Virt_ElementCapabilities association +KVM_ElementCapabilities root/virt Virt_ElementCapabilitiesProvider Virt_ElementCapabilities association diff -r 6dbbe2c148a7 -r 97209a4aec46 src/Virt_ElementCapabilities.c --- a/src/Virt_ElementCapabilities.c Mon Dec 03 13:01:53 2007 +0100 +++ b/src/Virt_ElementCapabilities.c Mon Dec 03 13:05:50 2007 +0100 @@ -359,8 +359,7 @@ struct std_assoc *assoc_handlers[] = { NULL }; -STDA_AssocMIStub(, Xen_ElementCapabilitiesProvider, _BROKER, libvirt_cim_init(), assoc_handlers); -STDA_AssocMIStub(, KVM_ElementCapabilitiesProvider, _BROKER, libvirt_cim_init(), assoc_handlers); +STDA_AssocMIStub(, Virt_ElementCapabilitiesProvider, _BROKER, libvirt_cim_init(), assoc_handlers); /* * Local Variables: * mode: C
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196683916 -3600 # Node ID 7c6276f57a7423a8c9a88fd48a3b4b7180948fd1 # Parent 97209a4aec46e659a9134dc28ac19c2f43b51c7c ESD: Provider registered per subclass The provider was registered for each subclass with a different name. That caused duplicated instances as the same provider gets called twice, but has no chance to figure out for which registration. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 97209a4aec46 -r 7c6276f57a74 schema/ElementSettingData.registration --- a/schema/ElementSettingData.registration Mon Dec 03 13:05:50 2007 +0100 +++ b/schema/ElementSettingData.registration Mon Dec 03 13:11:56 2007 +0100 @@ -1,4 +1,4 @@ # Copyright IBM Corp. 2007 -# Classname Namespace ProviderName ProviderModule ProviderTypes ... -Xen_ElementSettingData root/virt Xen_ElementSettingDataProvider Virt_ElementSettingData association -KVM_ElementSettingData root/virt KVM_ElementSettingDataProvider Virt_ElementSettingData association +# Classname Namespace ProviderName ProviderModule ProviderTypes +Xen_ElementSettingData root/virt Virt_ElementSettingDataProvider Virt_ElementSettingData association +KVM_ElementSettingData root/virt Virt_ElementSettingDataProvider Virt_ElementSettingData association diff -r 97209a4aec46 -r 7c6276f57a74 src/Virt_ElementSettingData.c --- a/src/Virt_ElementSettingData.c Mon Dec 03 13:05:50 2007 +0100 +++ b/src/Virt_ElementSettingData.c Mon Dec 03 13:11:56 2007 +0100 @@ -227,8 +227,7 @@ static struct std_assoc *handlers[] = { NULL }; -STDA_AssocMIStub(, Xen_ElementSettingDataProvider, _BROKER, libvirt_cim_init(), handlers); -STDA_AssocMIStub(, KVM_ElementSettingDataProvider, _BROKER, libvirt_cim_init(), handlers); +STDA_AssocMIStub(, Virt_ElementSettingDataProvider, _BROKER, libvirt_cim_init(), handlers); /* * Local Variables:
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196685310 -3600 # Node ID 495e8bdd4e1415b253fd64f0527760ad11b75580 # Parent 7c6276f57a7423a8c9a88fd48a3b4b7180948fd1 HS: Provider registered per subclass The provider was registered for each subclass with a different name. That caused duplicated instances as the same provider gets called twice, but has no chance to figure out for which registration. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 7c6276f57a74 -r 495e8bdd4e14 schema/HostedService.registration --- a/schema/HostedService.registration Mon Dec 03 13:11:56 2007 +0100 +++ b/schema/HostedService.registration Mon Dec 03 13:35:10 2007 +0100 @@ -1,4 +1,4 @@ # Copyright IBM Corp. 2007 -# Classname Namespace ProviderName ProviderModule ProviderTypes ... -Xen_HostedService root/virt Xen_HostedServiceProvider Virt_HostedService association -KVM_HostedService root/virt KVM_HostedServiceProvider Virt_HostedService association +# Classname Namespace ProviderName ProviderModule ProviderTypes +Xen_HostedService root/virt Virt_HostedServiceProvider Virt_HostedService association +KVM_HostedService root/virt Virt_HostedServiceProvider Virt_HostedService association diff -r 7c6276f57a74 -r 495e8bdd4e14 src/Virt_HostedService.c --- a/src/Virt_HostedService.c Mon Dec 03 13:11:56 2007 +0100 +++ b/src/Virt_HostedService.c Mon Dec 03 13:35:10 2007 +0100 @@ -159,8 +159,7 @@ static struct std_assoc *handlers[] = { NULL }; -STDA_AssocMIStub(, Xen_HostedServiceProvider, _BROKER, libvirt_cim_init(), handlers); -STDA_AssocMIStub(, KVM_HostedServiceProvider, _BROKER, libvirt_cim_init(), handlers); +STDA_AssocMIStub(, Virt_HostedServiceProvider, _BROKER, libvirt_cim_init(), handlers); /* * Local Variables:
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196685311 -3600 # Node ID 9fac31df90d1ce6279aff869ad9da51b411223e9 # Parent 495e8bdd4e1415b253fd64f0527760ad11b75580 RAFP: Provider registered per subclass The provider was registered for each subclass with a different name. That caused duplicated instances as the same provider gets called twice, but has no chance to figure out for which registration. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 495e8bdd4e14 -r 9fac31df90d1 schema/ResourceAllocationFromPool.registration --- a/schema/ResourceAllocationFromPool.registration Mon Dec 03 13:35:10 2007 +0100 +++ b/schema/ResourceAllocationFromPool.registration Mon Dec 03 13:35:11 2007 +0100 @@ -1,4 +1,4 @@ # Copyright IBM Corp. 2007 # Classname Namespace ProviderName ProviderModule ProviderTypes -Xen_ResourceAllocationFromPool root/virt Xen_ResourceAllocationFromPoolProvider Virt_ResourceAllocationFromPool association -KVM_ResourceAllocationFromPool root/virt KVM_ResourceAllocationFromPoolProvider Virt_ResourceAllocationFromPool association \ No newline at end of file +Xen_ResourceAllocationFromPool root/virt Virt_ResourceAllocationFromPoolProvider Virt_ResourceAllocationFromPool association +KVM_ResourceAllocationFromPool root/virt Virt_ResourceAllocationFromPoolProvider Virt_ResourceAllocationFromPool association \ No newline at end of file diff -r 495e8bdd4e14 -r 9fac31df90d1 src/Virt_ResourceAllocationFromPool.c --- a/src/Virt_ResourceAllocationFromPool.c Mon Dec 03 13:35:10 2007 +0100 +++ b/src/Virt_ResourceAllocationFromPool.c Mon Dec 03 13:35:11 2007 +0100 @@ -305,8 +305,7 @@ static struct std_assoc *handlers[] = { NULL }; -STDA_AssocMIStub(, Xen_ResourceAllocationFromPoolProvider, _BROKER, libvirt_cim_init(), handlers); -STDA_AssocMIStub(, KVM_ResourceAllocationFromPoolProvider, _BROKER, libvirt_cim_init(), handlers); +STDA_AssocMIStub(, Virt_ResourceAllocationFromPoolProvider, _BROKER, libvirt_cim_init(), handlers); /* * Local Variables:
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196685311 -3600 # Node ID 4caca9f23d36235f40a1011be956e3c8d135f77b # Parent 9fac31df90d1ce6279aff869ad9da51b411223e9 SDC: Provider registered per subclass The provider was registered for each subclass with a different name. That caused duplicated instances as the same provider gets called twice, but has no chance to figure out for which registration. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 9fac31df90d1 -r 4caca9f23d36 schema/SettingsDefineCapabilities.registration --- a/schema/SettingsDefineCapabilities.registration Mon Dec 03 13:35:11 2007 +0100 +++ b/schema/SettingsDefineCapabilities.registration Mon Dec 03 13:35:11 2007 +0100 @@ -1,4 +1,4 @@ # Copyright IBM Corp. 2007 # Classname Namespace ProviderName ProviderModule ProviderTypes -Xen_SettingsDefineCapabilities root/virt Xen_SettingsDefineCapabilitiesProvider Virt_SettingsDefineCapabilities association -KVM_SettingsDefineCapabilities root/virt KVM_SettingsDefineCapabilitiesProvider Virt_SettingsDefineCapabilities association +Xen_SettingsDefineCapabilities root/virt Virt_SettingsDefineCapabilitiesProvider Virt_SettingsDefineCapabilities association +KVM_SettingsDefineCapabilities root/virt Virt_SettingsDefineCapabilitiesProvider Virt_SettingsDefineCapabilities association diff -r 9fac31df90d1 -r 4caca9f23d36 src/Virt_SettingsDefineCapabilities.c --- a/src/Virt_SettingsDefineCapabilities.c Mon Dec 03 13:35:11 2007 +0100 +++ b/src/Virt_SettingsDefineCapabilities.c Mon Dec 03 13:35:11 2007 +0100 @@ -900,8 +900,7 @@ struct std_assoc *assoc_handlers[] = { }; -STDA_AssocMIStub(, Xen_SettingsDefineCapabilitiesProvider, _BROKER, libvirt_cim_init(), assoc_handlers); -STDA_AssocMIStub(, KVM_SettingsDefineCapabilitiesProvider, _BROKER, libvirt_cim_init(), assoc_handlers); +STDA_AssocMIStub(, Virt_SettingsDefineCapabilitiesProvider, _BROKER, libvirt_cim_init(), assoc_handlers); /* * Local Variables:
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196685312 -3600 # Node ID 909704b38ca4c9bfcb1121924053f26818d8316b # Parent 4caca9f23d36235f40a1011be956e3c8d135f77b SDS: Provider registered per subclass The provider was registered for each subclass with a different name. That caused duplicated instances as the same provider gets called twice, but has no chance to figure out for which registration. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 4caca9f23d36 -r 909704b38ca4 schema/SettingsDefineState.registration --- a/schema/SettingsDefineState.registration Mon Dec 03 13:35:11 2007 +0100 +++ b/schema/SettingsDefineState.registration Mon Dec 03 13:35:12 2007 +0100 @@ -1,4 +1,4 @@ # Copyright IBM Corp. 2007 # Classname Namespace ProviderName ProviderModule ProviderTypes -Xen_SettingsDefineState root/virt Xen_SettingsDefineStateProvider Virt_SettingsDefineState association -KVM_SettingsDefineState root/virt KVM_SettingsDefineStateProvider Virt_SettingsDefineState association +Xen_SettingsDefineState root/virt Virt_SettingsDefineStateProvider Virt_SettingsDefineState association +KVM_SettingsDefineState root/virt Virt_SettingsDefineStateProvider Virt_SettingsDefineState association diff -r 4caca9f23d36 -r 909704b38ca4 src/Virt_SettingsDefineState.c --- a/src/Virt_SettingsDefineState.c Mon Dec 03 13:35:11 2007 +0100 +++ b/src/Virt_SettingsDefineState.c Mon Dec 03 13:35:12 2007 +0100 @@ -399,8 +399,7 @@ static struct std_assoc *handlers[] = { NULL }; -STDA_AssocMIStub(, Xen_SettingsDefineStateProvider, _BROKER, libvirt_cim_init(), handlers); -STDA_AssocMIStub(, KVM_SettingsDefineStateProvider, _BROKER, libvirt_cim_init(), handlers); +STDA_AssocMIStub(, Virt_SettingsDefineStateProvider, _BROKER, libvirt_cim_init(), handlers); /* * Local Variables:
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196685313 -3600 # Node ID c6de8c296f561df41811ca04c2ea992b729cfea3 # Parent 909704b38ca4c9bfcb1121924053f26818d8316b SD: Provider registered per subclass The provider was registered for each subclass with a different name. That caused duplicated instances as the same provider gets called twice, but has no chance to figure out for which registration. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 909704b38ca4 -r c6de8c296f56 schema/SystemDevice.registration --- a/schema/SystemDevice.registration Mon Dec 03 13:35:12 2007 +0100 +++ b/schema/SystemDevice.registration Mon Dec 03 13:35:13 2007 +0100 @@ -1,4 +1,4 @@ # Copyright IBM Corp. 2007 # Classname Namespace ProviderName ProviderModule ProviderTypes -Xen_SystemDevice root/virt Xen_SystemDeviceProvider Virt_SystemDevice association -KVM_SystemDevice root/virt KVM_SystemDeviceProvider Virt_SystemDevice association +Xen_SystemDevice root/virt Virt_SystemDeviceProvider Virt_SystemDevice association +KVM_SystemDevice root/virt Virt_SystemDeviceProvider Virt_SystemDevice association diff -r 909704b38ca4 -r c6de8c296f56 src/Virt_SystemDevice.c --- a/src/Virt_SystemDevice.c Mon Dec 03 13:35:12 2007 +0100 +++ b/src/Virt_SystemDevice.c Mon Dec 03 13:35:13 2007 +0100 @@ -288,8 +288,7 @@ static struct std_assoc *assoc_handlers[ NULL }; -STDA_AssocMIStub(, Xen_SystemDeviceProvider, _BROKER, libvirt_cim_init(), assoc_handlers); -STDA_AssocMIStub(, KVM_SystemDeviceProvider, _BROKER, libvirt_cim_init(), assoc_handlers); +STDA_AssocMIStub(, Virt_SystemDeviceProvider, _BROKER, libvirt_cim_init(), assoc_handlers); /* * Local Variables:
HE> # HG changeset patch HE> # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> HE> # Date 1196685313 -3600 HE> # Node ID c6de8c296f561df41811ca04c2ea992b729cfea3 HE> # Parent 909704b38ca4c9bfcb1121924053f26818d8316b HE> SD: Provider registered per subclass Some of these providers still have ASSOC_MATCH() in them which, when combined with your s/Xen_/Virt_/ change to the provider name, causes them to always return no instances. I first noticed this with SystemDevice, but there are others in your set that need to have those calls removed. When I remove them, this patch seems fine to me. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196685314 -3600 # Node ID cd9afb53c5e76783d891d7bda74d1e642cf6701e # Parent c6de8c296f561df41811ca04c2ea992b729cfea3 VSSDC: Provider registered per subclass The provider was registered for each subclass with a different name. That caused duplicated instances as the same provider gets called twice, but has no chance to figure out for which registration. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r c6de8c296f56 -r cd9afb53c5e7 schema/VSSDComponent.registration --- a/schema/VSSDComponent.registration Mon Dec 03 13:35:13 2007 +0100 +++ b/schema/VSSDComponent.registration Mon Dec 03 13:35:14 2007 +0100 @@ -1,4 +1,4 @@ # Copyright IBM Corp. 2007 # Classname Namespace ProviderName ProviderModule ProviderTypes -Xen_VirtualSystemSettingDataComponent root/virt Xen_VSSDComponentProvider Virt_VSSDComponent association -KVM_VirtualSystemSettingDataComponent root/virt KVM_VSSDComponentProvider Virt_VSSDComponent association +Xen_VirtualSystemSettingDataComponent root/virt Virt_VSSDComponentProvider Virt_VSSDComponent association +KVM_VirtualSystemSettingDataComponent root/virt Virt_VSSDComponentProvider Virt_VSSDComponent association diff -r c6de8c296f56 -r cd9afb53c5e7 src/Virt_VSSDComponent.c --- a/src/Virt_VSSDComponent.c Mon Dec 03 13:35:13 2007 +0100 +++ b/src/Virt_VSSDComponent.c Mon Dec 03 13:35:14 2007 +0100 @@ -230,8 +230,7 @@ static struct std_assoc *handlers[] = { NULL }; -STDA_AssocMIStub(, Xen_VSSDComponentProvider, _BROKER, libvirt_cim_init(), handlers); -STDA_AssocMIStub(, KVM_VSSDComponentProvider, _BROKER, libvirt_cim_init(), handlers); +STDA_AssocMIStub(, Virt_VSSDComponentProvider, _BROKER, libvirt_cim_init(), handlers); /* * Local Variables:
HE> The association provider was registered for each subclass with a HE> different name. That caused duplicated instances as the same HE> provider gets called twice, but has no chance to figure out for HE> which registration. It does, actually, if you use ASSOC_MATCH(). That was the little hack we used to prevent duplicate entries while enumerating a CIM_Foo class while we were not using connect_by_classname(). However, I think that using the classname connection to prevent duplicates is better. Some care may be required in associations that do not have to connect to libvirt. HE> This patch set tries to fix it. Please review. Thanks. I tested EAFP and it works for me. I'll move on to test the rest, but feedback from others would be good. Thanks! -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Heidi Eckhart wrote:
The association provider was registered for each subclass with a different name. That caused duplicated instances as the same provider gets called twice, but has no chance to figure out for which registration. This patch set tries to fix it. Please review. Thanks.
Based on: - #2 Fix (again) VSMCaps and ElementCap - Remove devid-style InstanceID support from ELEC and EC
Applying these patches didn't fix the dups for me (btw, thanks for finding the dups!). I think the Virt_ provider still gets called twice. -- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
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. The unified case prevents us from having a key to filter on too. 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). 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? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
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. The unified case prevents us from having a key to filter on too.
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).
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. -- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
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
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
Kaitlin Rupert wrote: prefix. 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@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
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@us.ibm.com
Dan Smith wrote:
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.
Oh, both of these points are interesting - I didn't realize sfcb behaves differently (I've never used it). Thanks for bringing up this issue Heidi =) -- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
participants (3)
-
Dan Smith -
Heidi Eckhart -
Kaitlin Rupert