[PATCH] [TEST] Updating 02_enum_crscap.py tc of RedirectionService to work with libvirt-cim provider with no CRS CAP support
# HG changeset patch # User Deepti B. Kalakeri<deeptik@linux.vnet.ibm.com> # Date 1225804761 28800 # Node ID 82afd0f6f9b91ef42c6fd1602d9929faecb94c9e # Parent a63c661d0e709149d874d7632ac16f721aea60e6 [TEST] Updating 02_enum_crscap.py tc of RedirectionService to work with libvirt-cim provider with no CRS CAP support. Updating 02_enum_crscap.py tc of RedirectionService to skip the tc if CRS CAP provider is not present in the libvirt_cim provider when the libvirt_cim_revision < 691. Signed-off-by: Deepti B. Kalakeri <deeptik@linux.vnet.ibm.com> diff -r a63c661d0e70 -r 82afd0f6f9b9 suites/libvirt-cim/cimtest/RedirectionService/02_enum_crscap.py --- a/suites/libvirt-cim/cimtest/RedirectionService/02_enum_crscap.py Tue Nov 04 04:48:25 2008 -0800 +++ b/suites/libvirt-cim/cimtest/RedirectionService/02_enum_crscap.py Tue Nov 04 05:19:21 2008 -0800 @@ -31,15 +31,29 @@ from CimTest.Globals import logger, CIM_ERROR_ENUMERATE from XenKvmLib.classes import get_typed_class from XenKvmLib.const import do_main -from CimTest.ReturnCodes import PASS, FAIL +from CimTest.ReturnCodes import PASS, FAIL, SKIP +from XenKvmLib.const import get_provider_version SHAREMODESUPP = 3 sup_types = ['Xen', 'KVM', 'XenFV', 'LXC'] +libvirtcim_crscap_changes = 691 + @do_main(sup_types) def main(): virt = main.options.virt server = main.options.ip + + # This check is required for libivirt-cim providers which do not have + # CRSCAP changes in it and the CRSCAP provider is available with + # revision >= 691. + curr_cim_rev, changeset = get_provider_version(virt, server) + if curr_cim_rev < libvirtcim_crscap_changes: + logger.info("ConsoleRedirectionServiceCapabilities provider not" + " supported, hence skipping the tc ....") + return SKIP + + cname = 'ConsoleRedirectionServiceCapabilities' cap_name = 'ConsoleRedirectionCapabilities' classname = get_typed_class(virt, cname)
Deepti B. Kalakeri wrote:
# HG changeset patch # User Deepti B. Kalakeri<deeptik@linux.vnet.ibm.com> # Date 1225804761 28800 # Node ID 82afd0f6f9b91ef42c6fd1602d9929faecb94c9e # Parent a63c661d0e709149d874d7632ac16f721aea60e6 [TEST] Updating 02_enum_crscap.py tc of RedirectionService to work with libvirt-cim provider with no CRS CAP support.
Updating 02_enum_crscap.py tc of RedirectionService to skip the tc if CRS CAP provider is not present in the libvirt_cim provider when the libvirt_cim_revision < 691.
Signed-off-by: Deepti B. Kalakeri <deeptik@linux.vnet.ibm.com>
diff -r a63c661d0e70 -r 82afd0f6f9b9 suites/libvirt-cim/cimtest/RedirectionService/02_enum_crscap.py --- a/suites/libvirt-cim/cimtest/RedirectionService/02_enum_crscap.py Tue Nov 04 04:48:25 2008 -0800 +++ b/suites/libvirt-cim/cimtest/RedirectionService/02_enum_crscap.py Tue Nov 04 05:19:21 2008 -0800 @@ -31,15 +31,29 @@ from CimTest.Globals import logger, CIM_ERROR_ENUMERATE from XenKvmLib.classes import get_typed_class from XenKvmLib.const import do_main -from CimTest.ReturnCodes import PASS, FAIL +from CimTest.ReturnCodes import PASS, FAIL, SKIP +from XenKvmLib.const import get_provider_version
SHAREMODESUPP = 3
sup_types = ['Xen', 'KVM', 'XenFV', 'LXC'] +libvirtcim_crscap_changes = 691 + @do_main(sup_types) def main(): virt = main.options.virt server = main.options.ip + + # This check is required for libivirt-cim providers which do not have + # CRSCAP changes in it and the CRSCAP provider is available with + # revision >= 691. + curr_cim_rev, changeset = get_provider_version(virt, server) + if curr_cim_rev < libvirtcim_crscap_changes: + logger.info("ConsoleRedirectionServiceCapabilities provider not" + " supported, hence skipping the tc ....") + return SKIP + + cname = 'ConsoleRedirectionServiceCapabilities' cap_name = 'ConsoleRedirectionCapabilities' classname = get_typed_class(virt, cname)
This approach works for handling test cases that run against new providers. However, I think it'd be useful to have a function that calls GetClass() to determine whether the class is registered with the CIMOM. If the class isn't registered, the test would be skipped and an error message would be printed indicating that the class isn't registered. If all of the libvirt-cim classes aren't registered properly, then all of the tests would be skipped instead of all of them failing. This is something you could embed into the do_main() call, so that it happens before the test is even run. The tricky part is determining the classname or classnames associated with each test. I'm going to apply this change for now, and I'll add a to-do on the wiki for coming up with a way to check the classnames before running a test. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
Kaitlin Rupert wrote:
Deepti B. Kalakeri wrote:
# HG changeset patch # User Deepti B. Kalakeri<deeptik@linux.vnet.ibm.com> # Date 1225804761 28800 # Node ID 82afd0f6f9b91ef42c6fd1602d9929faecb94c9e # Parent a63c661d0e709149d874d7632ac16f721aea60e6 [TEST] Updating 02_enum_crscap.py tc of RedirectionService to work with libvirt-cim provider with no CRS CAP support.
Updating 02_enum_crscap.py tc of RedirectionService to skip the tc if CRS CAP provider is not present in the libvirt_cim provider when the libvirt_cim_revision < 691.
Signed-off-by: Deepti B. Kalakeri <deeptik@linux.vnet.ibm.com>
diff -r a63c661d0e70 -r 82afd0f6f9b9 suites/libvirt-cim/cimtest/RedirectionService/02_enum_crscap.py --- a/suites/libvirt-cim/cimtest/RedirectionService/02_enum_crscap.py Tue Nov 04 04:48:25 2008 -0800 +++ b/suites/libvirt-cim/cimtest/RedirectionService/02_enum_crscap.py Tue Nov 04 05:19:21 2008 -0800 @@ -31,15 +31,29 @@ from CimTest.Globals import logger, CIM_ERROR_ENUMERATE from XenKvmLib.classes import get_typed_class from XenKvmLib.const import do_main -from CimTest.ReturnCodes import PASS, FAIL +from CimTest.ReturnCodes import PASS, FAIL, SKIP +from XenKvmLib.const import get_provider_version
SHAREMODESUPP = 3
sup_types = ['Xen', 'KVM', 'XenFV', 'LXC'] +libvirtcim_crscap_changes = 691 + @do_main(sup_types) def main(): virt = main.options.virt server = main.options.ip + + # This check is required for libivirt-cim providers which do not have + # CRSCAP changes in it and the CRSCAP provider is available with + # revision >= 691. + curr_cim_rev, changeset = get_provider_version(virt, server) + if curr_cim_rev < libvirtcim_crscap_changes: + logger.info("ConsoleRedirectionServiceCapabilities provider not" + " supported, hence skipping the tc ....") + return SKIP + + cname = 'ConsoleRedirectionServiceCapabilities' cap_name = 'ConsoleRedirectionCapabilities' classname = get_typed_class(virt, cname)
This approach works for handling test cases that run against new providers. However, I think it'd be useful to have a function that calls GetClass() to determine whether the class is registered with the CIMOM. If the class isn't registered, the test would be skipped and an error message would be printed indicating that the class isn't registered.
If all of the libvirt-cim classes aren't registered properly, then all of the tests would be skipped instead of all of them failing.
This is something you could embed into the do_main() call, so that it happens before the test is even run. The tricky part is determining the classname or classnames associated with each test.
I'm going to apply this change for now, and I'll add a to-do on the wiki for coming up with a way to check the classnames before running a test.
Yes I agree with you that we need to better the way to verify if tc in a particular directory needs to be run or not. This has two fold advantage: 1) It will tell us if the providers are registered properly or not, if its a setup issue. 2) It will save some batch test run time, by skipping those directories. Implementing this is not straight forward though. Here is an initial thought how we can implement this check Once the test run in batch mode is started even before we invoke the tests, we can have a list of all the providers which we think should be present for the providers to be verified. We can then have two list 1) The first list should contain information of the providers which are registered on the machine and the tests for which have to be run. 2) Second list should contain the list of all providers which have not been registered on the machine. -- The error here would depend on two things: -- If the providers is not registered properly because of the setup issue -- Or the provider is not registered since the installed source/ rpm does not yet contain support for that particular provider. Thanks and Regards, Deepti.
Yes I agree with you that we need to better the way to verify if tc in a particular directory needs to be run or not. This has two fold advantage: 1) It will tell us if the providers are registered properly or not, if its a setup issue. 2) It will save some batch test run time, by skipping those directories.
Implementing this is not straight forward though. Here is an initial thought how we can implement this check
Once the test run in batch mode is started even before we invoke the tests, we can have a list of all the providers which we think should be present for the providers to be verified. We can then have two list 1) The first list should contain information of the providers which are registered on the machine and the tests for which have to be run.
My concern with this kind of approach is the maintainability of the lists. Each time a test is updated to support a new provider, the test writer also needs to update the list. There's over a hundred tests, so the list would be quite large already, and it would only continue to grow. Most of the tests query several different providers, so this would make the list somewhat complex. I was thinking of each test maintaining its own list of providers it tests, and then having the test suite check the test case's list before calling the test.
2) Second list should contain the list of all providers which have not been registered on the machine.
This kind of list should be easy to generate. I would generate a list of providers that have been registered. If the list is empty, you could bail from the test suite before even attempting to run any of the tests. It'd be a good first check.
-- The error here would depend on two things: -- If the providers is not registered properly because of the setup issue -- Or the provider is not registered since the installed source/ rpm does not yet contain support for that particular provider.
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
participants (3)
-
Deepti B Kalakeri -
Deepti B. Kalakeri
-
Kaitlin Rupert