[PATCH] [TEST] Updating 02_enum_crscap.py tc of RedirectionService to work with libvirt-cim provider with no CRS CAP support
7:19 a.m.
# HG changeset patch
# User Deepti B. Kalakeri<deeptik(a)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(a)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)
12:30 p.m.
Deepti B. Kalakeri wrote:
# HG changeset patch
# User Deepti B. Kalakeri<deeptik(a)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(a)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(a)linux.vnet.ibm.com
11:49 p.m.
Kaitlin Rupert wrote:
Deepti B. Kalakeri wrote:
> # HG changeset patch
> # User Deepti B. Kalakeri<deeptik(a)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(a)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.
1:07 p.m.
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(a)linux.vnet.ibm.com
5843
days inactive
5845
days old
3 comments
3 participants
participants (3)
-
Deepti B Kalakeri -
Deepti B. Kalakeri
-
Kaitlin Rupert