3:05 a.m.
# HG changeset patch
# User Zhengang Li <lizg(a)cn.ibm.com>
# Date 1207728305 25200
# Node ID be122f36acaa24527bdc6339ed16b80526b5fcb7
# Parent f58194a3271fe20b19894c9f3472164316e1ee4c
[TEST] change AllocationCapabilities expected error string
On FC8 it was 'Instance not found'. Now FC9 expects 'Requested
Object could not be found'. This is only a string returned from
CIMOM, I'm changing this to a word used in both messages. What
we really expect is the CIM_ERR_NOT_FOUND. The rc code are identical
on FC8 and FC9.
This fixes AllocationCapabilities.02 failures on a pegasus 2.7 CIMOM.
Signed-off-by: Zhengang Li <lizg(a)cn.ibm.com>
diff -r f58194a3271f -r be122f36acaa
suites/libvirt-cim/cimtest/AllocationCapabilities/02_alloccap_gi_errs.py
--- a/suites/libvirt-cim/cimtest/AllocationCapabilities/02_alloccap_gi_errs.py Wed Apr 09
00:57:03 2008 -0700
+++ b/suites/libvirt-cim/cimtest/AllocationCapabilities/02_alloccap_gi_errs.py Wed Apr 09
01:05:05 2008 -0700
@@ -73,7 +73,7 @@
"invalid_instid_keyname" : { 'rc' :
pywbem.CIM_ERR_FAILED, \
'desc' : 'No InstanceID
specified' }, \
"invalid_instid_keyvalue" : { 'rc' :
pywbem.CIM_ERR_NOT_FOUND, \
- 'desc' : 'Instance not
found' }
+ 'desc' : 'found' }
}
def conf_file():
"""
10:38 a.m.
zli(a)linux.vnet.ibm.com wrote:
# HG changeset patch
# User Zhengang Li <lizg(a)cn.ibm.com>
# Date 1207728305 25200
# Node ID be122f36acaa24527bdc6339ed16b80526b5fcb7
# Parent f58194a3271fe20b19894c9f3472164316e1ee4c
[TEST] change AllocationCapabilities expected error string
On FC8 it was 'Instance not found'. Now FC9 expects 'Requested
Object could not be found'. This is only a string returned from
CIMOM, I'm changing this to a word used in both messages. What
we really expect is the CIM_ERR_NOT_FOUND. The rc code are identical
on FC8 and FC9.
This fixes AllocationCapabilities.02 failures on a pegasus 2.7 CIMOM.
Signed-off-by: Zhengang Li <lizg(a)cn.ibm.com>
diff -r f58194a3271f -r be122f36acaa
suites/libvirt-cim/cimtest/AllocationCapabilities/02_alloccap_gi_errs.py
--- a/suites/libvirt-cim/cimtest/AllocationCapabilities/02_alloccap_gi_errs.py Wed Apr 09
00:57:03 2008 -0700
+++ b/suites/libvirt-cim/cimtest/AllocationCapabilities/02_alloccap_gi_errs.py Wed Apr 09
01:05:05 2008 -0700
@@ -73,7 +73,7 @@
"invalid_instid_keyname" : { 'rc' :
pywbem.CIM_ERR_FAILED, \
'desc' : 'No InstanceID
specified' }, \
"invalid_instid_keyvalue" : { 'rc' :
pywbem.CIM_ERR_NOT_FOUND, \
- 'desc' : 'Instance not
found' }
+ 'desc' : 'found' }
}
def conf_file():
"""
While this makes the test pass, I think there's potential for a false
positive here. Some providers return messages like:
"System Name not found" and "CreationClassName not found."
Using just "found" would cause the test to pass in both cases, even
though we really only want to pass if we get "System Name not found."
A suggestion is to have the ability to check multiple descriptions. So
then you could check against the expected error messages for both F8 and F9.
The hope here is that the error messages don't change often. Thoughts?
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com
3:49 p.m.
KR> The hope here is that the error messages don't change often.
KR> Thoughts?
I think the only thing you should depend on is the return code.
Interpreting the error string is likely to break.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com
6:30 p.m.
Dan Smith wrote:
KR> The hope here is that the error messages don't change
often.
KR> Thoughts?
I think the only thing you should depend on is the return code.
Interpreting the error string is likely to break.
Agreed - verifying the strings has been an upkeep headache.
However, a provider can fail for a number of reasons and return the same
error code for each one. Unfortunately (in the case anyway), CIM has
such a small subset of return codes. So you can't accurately confirm
that the test failed for the proper reason.
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com
6:48 p.m.
KR> However, a provider can fail for a number of reasons and return the
KR> same error code for each one. Unfortunately (in the case anyway), CIM
KR> has such a small subset of return codes. So you can't accurately
KR> confirm that the test failed for the proper reason.
Well, we can return provider-specific error codes in addition to the
CIM-standard ones. We could conceivably add those into places where
we need a more information about a particular failure case.
Also, if we're not expecting an error, we should be sure to FAIL if
the return is not CMPI_RC_OK, and then try to resolve the error
code/message to a specific case if possible.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com
6:55 p.m.
Dan Smith wrote:
KR> However, a provider can fail for a number of reasons and
return the
KR> same error code for each one. Unfortunately (in the case anyway), CIM
KR> has such a small subset of return codes. So you can't accurately
KR> confirm that the test failed for the proper reason.
Well, we can return provider-specific error codes in addition to the
CIM-standard ones. We could conceivably add those into places where
we need a more information about a particular failure case.
Also, if we're not expecting an error, we should be sure to FAIL if
the return is not CMPI_RC_OK, and then try to resolve the error
code/message to a specific case if possible.
That would be useful, but also sounds like a fair bit of work. I see
how it'd be useful for testing, but I'm not sure how useful it is for a
regular consumer.
I suppose for error reporting, users would then be able to supply the
provider specific error code, which would be more meaningful to use than
CMPI_RC_ERR_FAILED.
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com
6101
days inactive
6101
days old
5 comments
3 participants
participants (3)
-
Dan Smith -
Kaitlin Rupert -
zli＠linux.vnet.ibm.com