[PATCH] SD doesn't return instances in all cases
# HG changeset patch # User Kaitlin Rupert <karupert@us.ibm.com> # Date 1196460977 28800 # Node ID 1776beb36f5cffcfad4e581a8841f77f20bc3927 # Parent d5af3e219c22e8b32de64c69a29aea970ab6a9a4 SD doesn't return instances in all cases. Virt_SystemDevice doesn't return instances when CIM_ManagedElement is passed as a result class argument. This only applies to the VM to device case (see failint query below). The problem is that we use the result class to determine which device type to return. If no result class is specified, we return all associated devices. However, if CIM_ManagedElement is specified, we are unable to match the device type, and we return nothing. I think all of this can be removed because filter_results() in libcmpiutil should remove the need for this kind of checking. Failing query: wbemcli ain -ac Xen_SystemDevice -arc CIM_ManagedElement 'http://root:elm3b41@localhost/root/virt:Xen_ComputerSystem.CreationClassName="Xen_ComputerSystem",Name="Domain-0"' Signed-off-by: Kaitlin Rupert <karupert@us.ibm.com> diff -r d5af3e219c22 -r 1776beb36f5c src/Virt_SystemDevice.c --- a/src/Virt_SystemDevice.c Fri Nov 30 11:33:21 2007 -0800 +++ b/src/Virt_SystemDevice.c Fri Nov 30 14:16:17 2007 -0800 @@ -171,22 +171,10 @@ static CMPIStatus sys_to_dev(const CMPIO goto out; } - if (info->result_class) { - int type; - - type = device_type_from_classname(info->result_class); - - ret = get_dom_devices(host, - list, - type, - CLASSNAME(ref), - NAMESPACE(ref)); - } else { - ret = get_all_devices(host, - list, - CLASSNAME(ref), - NAMESPACE(ref)); - } + ret = get_all_devices(host, + list, + CLASSNAME(ref), + NAMESPACE(ref)); if (ret >= 0) { CMSetStatus(&s, CMPI_RC_OK);
KR> I think all of this can be removed because filter_results() in KR> libcmpiutil should remove the need for this kind of checking. Yeah, which is really handy. I can see this becoming an issue later strictly for performance, but I think that this is fine for now and we can reintroduce the optimization (correctly) if we decide it's needed. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
KR> I think all of this can be removed because filter_results() in KR> libcmpiutil should remove the need for this kind of checking.
Yeah, which is really handy.
I can see this becoming an issue later strictly for performance, but I think that this is fine for now and we can reintroduce the optimization (correctly) if we decide it's needed. Now, that you both pick up the filter_results() function, this is a good time to enter this discussion. I agree that the filter_results() function is handy and takes away a lot of checking and distinguishing from the provider. For tiny numbers of returned instances and fast systems, this will not cause any problems. But we should keep in mind,
Good catch Kaitlin :). Dan Smith wrote: that the providers should also scale for a large number of virtual machines. As Dan already mentioned - this approach will become an performance issue later. On the other hand its more the responsibility of the provider - especially for our ones, that handle a lot of subclasses at one time - to filter the returned instances, as the responsibility of the generic association logic. So I want to follow Dan's opinion and keep it for now. But we should add this to our ToDo list and fix as time allows. I suppose this will mean to reorganize the providers a bit and I do not expect a huge effort. -- 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
Heidi Eckhart wrote:
optimization (correctly) if we decide it's needed. Now, that you both pick up the filter_results() function, this is a good time to enter this discussion. I agree that the filter_results() function is handy and takes away a lot of checking and distinguishing from the provider. For tiny numbers of returned instances and fast systems, this will not cause any problems. But we should keep in mind, that the providers should also scale for a large number of virtual machines. As Dan already mentioned - this approach will become an performance issue later. On the other hand its more the responsibility of the provider - especially for our ones, that handle a lot of subclasses at one time - to filter the returned instances, as the responsibility of the generic association logic. So I want to follow Dan's opinion and keep it for now. But we should add this to our ToDo list and fix as time allows. I suppose this will mean to reorganize the providers a bit and I do not expect a huge effort.
I agree - I was concerned about performance when I wrote the filter_results() code. =) It would probably be a good idea to test all of the providers for performance at some point. Since the enum extrinsic functions don't return until all the instances are generate, you could potentially run into some performance issues there as well. -- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
participants (3)
-
Dan Smith -
Heidi Eckhart -
Kaitlin Rupert