[PATCH] [TEST] change AllocationCapabilities expected error string
# HG changeset patch # User Zhengang Li <lizg@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@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(): """
zli@linux.vnet.ibm.com wrote:
# HG changeset patch # User Zhengang Li <lizg@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@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@linux.vnet.ibm.com
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@us.ibm.com
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@linux.vnet.ibm.com
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@us.ibm.com
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@linux.vnet.ibm.com
participants (3)
-
Dan Smith -
Kaitlin Rupert -
zli＠linux.vnet.ibm.com