6:21 a.m.
# HG changeset patch
# User Kaitlin Rupert <karupert(a)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(a)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);
6:22 a.m.
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(a)us.ibm.com
5:21 p.m.
Good catch Kaitlin :).
Dan Smith wrote:
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,
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(a)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
7 a.m.
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(a)us.ibm.com
6122
days inactive
6126
days old
3 comments
3 participants
participants (3)
-
Dan Smith -
Heidi Eckhart -
Kaitlin Rupert