Now that we started moving to conform with pep8 you would probably like to be able to easily check your code.
If you use vim you could use this vim script http://www.vim.org/scripts/script.php?script_id=2914
I you are not using vim follow these 3 simple steps: 1. Switch to vim 2. Install the script 3. Profit
On Thu, Apr 12, 2012 at 10:48:26AM -0400, Saggi Mizrahi wrote:
Now that we started moving to conform with pep8 you would probably like to be able to easily check your code.
If you use vim you could use this vim script http://www.vim.org/scripts/script.php?script_id=2914
I you are not using vim follow these 3 simple steps:
- Switch to vim
- Install the script
- Profit
While we're exchanging cool vim plugins I can recommend syntastic[1] to you which has plugins for pylint, pyflakes and flake8. That last one can also check pep8.
On 04/12/2012 10:48 PM, Saggi Mizrahi wrote:
Now that we started moving to conform with pep8 you would probably like to be able to easily check your code.
If you use vim you could use this vim script http://www.vim.org/scripts/script.php?script_id=2914
I check PEP8 based on this version and it passed with no noise.
But seems it failed to vdsm_unit_test with 'E261 at least two spaces before inline comment.' And this version can find the E261 error too: https://github.com/jcrocholl/pep8/branches/master
Also I found otherinconsistent check result from different python-pep8 versions. So I think It is necessary to have auniformstandard for pep8 in vdsm to avoid such noise.
I you are not using vim follow these 3 simple steps:
- Switch to vim
- Install the script
- Profit
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
On Tue, Apr 24, 2012 at 10:39:24AM +0800, Lei Li wrote:
On 04/12/2012 10:48 PM, Saggi Mizrahi wrote:
Now that we started moving to conform with pep8 you would probably like to be able to easily check your code.
If you use vim you could use this vim script http://www.vim.org/scripts/script.php?script_id=2914
I check PEP8 based on this version and it passed with no noise.
But seems it failed to vdsm_unit_test with 'E261 at least two spaces before inline comment.' And this version can find the E261 error too: https://github.com/jcrocholl/pep8/branches/master
Also I found otherinconsistent check result from different python-pep8 versions. So I think It is necessary to have auniformstandard for pep8 in vdsm to avoid such noise.
I'd say that the version running in jenkins.ovirt.org is our de-facto standard (python-pep8-0.6.0-3.fc15.noarch I believe).
Hello, I am planning to let vdsm use python 2.7.3 for that race condition was found in subprocess.Popen and threading.Thread in python 2.7.2 on Fedora 16. The test case could be found in previous mails. gerrit: http://gerrit.ovirt.org/#change,3638 Python 2.7.3 on Fedora could be got from : https://bugzilla.redhat.com/show_bug.cgi?id=814492 Any comments are welcome.
thanks.
On Tue, Apr 24, 2012 at 05:10:40PM +0800, wenchao xia wrote:
Hello, I am planning to let vdsm use python 2.7.3 for that race condition was found in subprocess.Popen and threading.Thread in python 2.7.2 on Fedora 16. The test case could be found in previous mails. gerrit: http://gerrit.ovirt.org/#change,3638 Python 2.7.3 on Fedora could be got from : https://bugzilla.redhat.com/show_bug.cgi?id=814492 Any comments are welcome.
It is important to mention that this is python version is not in f16 yet. One would have to --enablerepo=updates-testing in order to take it. I would like to inform Jenkins folks about this beforehence.
Wenchao, could you (or someone else) double-check that this bug is really fixed in el6's python 2.6.6 ?
Regards, Dan.
Tested again on el6.2, passed. With more test and code reading of cpython, I think this bug is introduced by a bugfix in python: http://bugs.python.org/issue13156 The patch solving the bug I met in python2.7.2, is: changeset: 72897:ee4fe16d9b48 branch: 2.7 parent: 69635:f6feed6ec3f9 user: Charles-Fran?ois Natali neologix@free.fr date: Wed Oct 12 21:07:54 2011 +0200 summary: Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for native It does a revert operation, So that explains why error do not happen in python 2.7.3 and python 2.6.6.
On Tue, Apr 24, 2012 at 05:10:40PM +0800, wenchao xia wrote:
Hello, I am planning to let vdsm use python 2.7.3 for that race condition was found in subprocess.Popen and threading.Thread in python 2.7.2 on Fedora 16. The test case could be found in previous mails. gerrit: http://gerrit.ovirt.org/#change,3638 Python 2.7.3 on Fedora could be got from : https://bugzilla.redhat.com/show_bug.cgi?id=814492 Any comments are welcome.
It is important to mention that this is python version is not in f16 yet. One would have to --enablerepo=updates-testing in order to take it. I would like to inform Jenkins folks about this beforehence.
Wenchao, could you (or someone else) double-check that this bug is really fixed in el6's python 2.6.6 ?
Regards, Dan.
Tested again on el6.2, passed. With more test and code reading of cpython, I think this bug is introduced by a bugfix in python: http://bugs.python.org/issue13156 The patch solving the bug I met in python2.7.2, is: changeset: 72897:ee4fe16d9b48 branch: 2.7 parent: 69635:f6feed6ec3f9 user: Charles-Fran?ois Natali neologix@free.fr date: Wed Oct 12 21:07:54 2011 +0200 summary: Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for native It does a revert operation, So that explains why error do not happen in python 2.7.3 and python 2.6.6.
On Tue, Apr 24, 2012 at 05:10:40PM +0800, wenchao xia wrote:
Hello, I am planning to let vdsm use python 2.7.3 for that race condition was found in subprocess.Popen and threading.Thread in python 2.7.2 on Fedora 16. The test case could be found in previous mails. gerrit: http://gerrit.ovirt.org/#change,3638 Python 2.7.3 on Fedora could be got from : https://bugzilla.redhat.com/show_bug.cgi?id=814492 Any comments are welcome.
It is important to mention that this is python version is not in f16 yet. One would have to --enablerepo=updates-testing in order to take it. I would like to inform Jenkins folks about this beforehence.
Wenchao, could you (or someone else) double-check that this bug is really fixed in el6's python 2.6.6 ?
Regards, Dan.
On Wed, Apr 25, 2012 at 05:17:47PM +0800, wenchao xia wrote:
Tested again on el6.2, passed. With more test and code reading of cpython, I think this bug is introduced by a bugfix in python: http://bugs.python.org/issue13156 The patch solving the bug I met in python2.7.2, is: changeset: 72897:ee4fe16d9b48 branch: 2.7 parent: 69635:f6feed6ec3f9 user: Charles-Fran?ois Natali neologix@free.fr date: Wed Oct 12 21:07:54 2011 +0200 summary: Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for native It does a revert operation, So that explains why error do not happen in python 2.7.3 and python 2.6.6.
On Tue, Apr 24, 2012 at 05:10:40PM +0800, wenchao xia wrote:
Hello, I am planning to let vdsm use python 2.7.3 for that race condition was found in subprocess.Popen and threading.Thread in python 2.7.2 on Fedora 16. The test case could be found in previous mails. gerrit: http://gerrit.ovirt.org/#change,3638 Python 2.7.3 on Fedora could be got from : https://bugzilla.redhat.com/show_bug.cgi?id=814492 Any comments are welcome.
It is important to mention that this is python version is not in f16 yet. One would have to --enablerepo=updates-testing in order to take it. I would like to inform Jenkins folks about this beforehence.
Wenchao, could you (or someone else) double-check that this bug is really fixed in el6's python 2.6.6 ?
Thanks, Wenchao. If current users users of vdsm in Fedora16 does not object, I'll take the new req.
Regards, Dan.
Hello, vdsm now have UT suits for developer, but sometimes building and installation machine is not the same one, and additional check is need which is ignored at building time, so I think some test cases should be also run on target machine to check potential errors, Then I want to introduce a sub package as VT suits. Purpose: UT: for developers, more likely a white box, running on building environment. VT: for user and deployment, more likely a black box, running on product or testing environment, all known issue should be covered.
Supposed approach: 1 modify building system to generate package: vdsm-VT.rpm. 2 install as an option, after install, user type "vdsm-VT" would make the test begin.
Planned details: 1 Going to place cases in vdsm project in ./tests/VT. 2 On installation will move some useful UT cases into VT. 3 use same framework UT used. 4 two sub dir in test/VT: user_case_test;general_test.
It is just a scratch from my mind, so I'd like hear your opinions.
Best Regargs:
Wenchao Xia
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
Hello, vdsm now have UT suits for developer, but sometimes building and installation machine is not the same one, and additional check is need which is ignored at building time, so I think some test cases should be also run on target machine to check potential errors, Then I want to introduce a sub package as VT suits. Purpose: UT: for developers, more likely a white box, running on building environment. VT: for user and deployment, more likely a black box, running on product or testing environment, all known issue should be covered.
Supposed approach: 1 modify building system to generate package: vdsm-VT.rpm.
I would prefer the package name 'vdsm-test.rpm' and this package should include unit tests and verification tests.
2 install as an option, after install, user type "vdsm-VT" would make the test begin.
The test runner should be able to run the full suite of unit tests and verification tests (with an option to run only unit tests or only verification tests). This can be the same program that we use in the build environment except that it will set the PYTHONPATH differently to target the installed files.
Planned details: 1 Going to place cases in vdsm project in ./tests/VT. 2 On installation will move some useful UT cases into VT.
If you follow my approach above, you would simply package the whole tests/ directory and no copying would be necessary.
3 use same framework UT used. 4 two sub dir in test/VT: user_case_test;general_test.
What is the difference between these two types of tests?
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
One more comment about the test package version. Most likely, the package version will be the same version as the VDSM package version. The rule we need to consider is: Should we keep the back compatibility with the VDSM files? Say allow newer version test package running on older VDSM files? Or just allow run the same version of test package and VDSM package.
Thanks Ming
"Adam Litke" agl@us.ibm.com To 2012-04-26 21:57 wenchao xia xiaxia347os@163.com cc Dan Kenigsberg danken@redhat.com, Ayal Baron abaron@redhat.com, vdsm-devel@lists.fedorahosted.org, Ming M Shu/China/IBM@IBMCN Subject Re: [vdsm] Introducing a validation test package to vdsm
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
Hello, vdsm now have UT suits for developer, but sometimes building and installation machine is not the same one, and additional check is need which is ignored at building time, so I think some test cases should be also run on target machine to check potential errors, Then I want to introduce a sub package as VT suits. Purpose: UT: for developers, more likely a white box, running on building environment. VT: for user and deployment, more likely a black box, running on product or testing environment, all known issue should be covered.
Supposed approach: 1 modify building system to generate package: vdsm-VT.rpm.
I would prefer the package name 'vdsm-test.rpm' and this package should include unit tests and verification tests.
2 install as an option, after install, user type "vdsm-VT" would make the test begin.
The test runner should be able to run the full suite of unit tests and verification tests (with an option to run only unit tests or only verification tests). This can be the same program that we use in the build environment except that it will set the PYTHONPATH differently to target the installed files.
Planned details: 1 Going to place cases in vdsm project in ./tests/VT. 2 On installation will move some useful UT cases into VT.
If you follow my approach above, you would simply package the whole tests/ directory and no copying would be necessary.
3 use same framework UT used. 4 two sub dir in test/VT: user_case_test;general_test.
What is the difference between these two types of tests?
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
-- Adam Litke agl@us.ibm.com IBM Linux Technology Center
On Thu, Apr 26, 2012 at 08:57:55AM -0500, Adam Litke wrote:
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
Reminds me of Ganeti burnin. From the manpage[1]:
This tool is used to exercise either the hardware of machines or alternatively the Ganeti software. It is safe to run on an existing cluster as long as you don’t pass it existing instance names.
The command will, by default, execute a comprehensive set of operations against a list of instances, these being:
creation disk replacement (for redundant instances) failover and migration (for redundant instances) move (for non-redundant instances) disk growth add disks, remove disk add NICs, remove NICs export and then import rename reboot shutdown/startup and finally removal of the test instances
Executing all these operations will test that the hardware performs well: the creation, disk replace, disk add and disk growth will exercise the storage and network; the migrate command will test the memory of the systems. Depending on the passed options, it can also test that the instance OS definitions are executing properly the rename, import and export operations.
[1]: http://docs.ganeti.org/ganeti/2.5/html/admin.html#burnin
On 04/26/2012 10:35 PM, Ewoud Kohl van Wijngaarden wrote:
On Thu, Apr 26, 2012 at 08:57:55AM -0500, Adam Litke wrote:
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
Reminds me of Ganeti burnin. From the manpage[1]:
This tool is used to exercise either the hardware of machines or alternatively the Ganeti software. It is safe to run on an existing cluster as long as you don’t pass it existing instance names.
The command will, by default, execute a comprehensive set of operations against a list of instances, these being:
creation disk replacement (for redundant instances) failover and migration (for redundant instances) move (for non-redundant instances) disk growth add disks, remove disk add NICs, remove NICs export and then import rename reboot shutdown/startup and finally removal of the test instances
Executing all these operations will test that the hardware performs well: the creation, disk replace, disk add and disk growth will exercise the storage and network; the migrate command will test the memory of the systems. Depending on the passed options, it can also test that the instance OS definitions are executing properly the rename, import and export operations.
These operations are different with units test. Should these operations be test on a really environnement, which include cluster and storage server and the net-work ? It is OK, that seems unit tests run on laptop.
So I think these test should not be in the vdsm packet, should be a new packet.
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
于 2012-4-26 22:35, Ewoud Kohl van Wijngaarden 写道:
On Thu, Apr 26, 2012 at 08:57:55AM -0500, Adam Litke wrote:
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
Reminds me of Ganeti burnin. From the manpage[1]:
This tool is used to exercise either the hardware of machines or alternatively the Ganeti software. It is safe to run on an existing cluster as long as you don’t pass it existing instance names.
The command will, by default, execute a comprehensive set of operations against a list of instances, these being:
creation disk replacement (for redundant instances) failover and migration (for redundant instances) move (for non-redundant instances) disk growth add disks, remove disk add NICs, remove NICs export and then import rename reboot shutdown/startup and finally removal of the test instances
Executing all these operations will test that the hardware performs well: the creation, disk replace, disk add and disk growth will exercise the storage and network; the migrate command will test the memory of the systems. Depending on the passed options, it can also test that the instance OS definitions are executing properly the rename, import and export operations.
This seems a stress test or cluster test tool, and I think vdsm cares about the node's capability. My original idea is provide a tool to make sure vdsm works as expect on a node, so I think it should be another suits calling all nodes using the Ganeti burnin.
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
On Fri, Apr 27, 2012 at 11:23:49AM +0800, wenchao xia wrote:
于 2012-4-26 22:35, Ewoud Kohl van Wijngaarden 写道:
On Thu, Apr 26, 2012 at 08:57:55AM -0500, Adam Litke wrote:
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
Reminds me of Ganeti burnin. From the manpage[1]:
This tool is used to exercise either the hardware of machines or alternatively the Ganeti software. It is safe to run on an existing cluster as long as you don’t pass it existing instance names.
The command will, by default, execute a comprehensive set of operations against a list of instances, these being:
creation disk replacement (for redundant instances) failover and migration (for redundant instances) move (for non-redundant instances) disk growth add disks, remove disk add NICs, remove NICs export and then import rename reboot shutdown/startup and finally removal of the test instances
Executing all these operations will test that the hardware performs well: the creation, disk replace, disk add and disk growth will exercise the storage and network; the migrate command will test the memory of the systems. Depending on the passed options, it can also test that the instance OS definitions are executing properly the rename, import and export operations.
This seems a stress test or cluster test tool, and I think vdsm cares about the node's capability. My original idea is provide a tool to make sure vdsm works as expect on a node, so I think it should be another suits calling all nodes using the Ganeti burnin.
True, burnin might be more of an engine test than vdsm.
One more comment about the test package version. Most likely, the package version will be the same version as the VDSM package version. The rule we need to consider is: Should we keep the back compatibility with the VDSM files? Say allow newer version test package running on older VDSM files? Or just allow run the same version of test package and VDSM package.One more comment about the test package version. Most likely, the package version will be the same version as the VDSM package version. The rule we need to consider is: Should we keep the back compatibility with the VDSM files? Say allow newer version test package running on older VDSM files? Or just allow run the same version of test package and VDSM package.
On 2012-4-26 21:57, Adam Litke wrote:
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
Hello, vdsm now have UT suits for developer, but sometimes building and installation machine is not the same one, and additional check is need which is ignored at building time, so I think some test cases should be also run on target machine to check potential errors, Then I want to introduce a sub package as VT suits. Purpose: UT: for developers, more likely a white box, running on building environment. VT: for user and deployment, more likely a black box, running on product or testing environment, all known issue should be covered.
Supposed approach: 1 modify building system to generate package: vdsm-VT.rpm.
I would prefer the package name 'vdsm-test.rpm' and this package should include unit tests and verification tests.
2 install as an option, after install, user type "vdsm-VT" would make the test begin.
The test runner should be able to run the full suite of unit tests and verification tests (with an option to run only unit tests or only verification tests). This can be the same program that we use in the build environment except that it will set the PYTHONPATH differently to target the installed files.
Planned details: 1 Going to place cases in vdsm project in ./tests/VT. 2 On installation will move some useful UT cases into VT.
If you follow my approach above, you would simply package the whole tests/ directory and no copying would be necessary.
3 use same framework UT used. 4 two sub dir in test/VT: user_case_test;general_test.
What is the difference between these two types of tests?
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
On Thu, Apr 26, 2012 at 11:12:06PM +0800, Shu Ming wrote:
One more comment about the test package version. Most likely, the package version will be the same version as the VDSM package version. The rule we need to consider is: Should we keep the back compatibility with the VDSM files? Say allow newer version test package running on older VDSM files? Or just allow run the same version of test package and VDSM package.One more comment about the test package version. Most likely, the package version will be the same version as the VDSM package version. The rule we need to consider is: Should we keep the back compatibility with the VDSM files? Say allow newer version test package running on older VDSM files? Or just allow run the same version of test package and VDSM package.
Backwards-compatible tests is not a good idea in my opinion. I would say that the test rpm should require the exact same vdsm version.
On 2012-4-26 21:57, Adam Litke wrote:
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
Hello, vdsm now have UT suits for developer, but sometimes building and installation machine is not the same one, and additional check is need which is ignored at building time, so I think some test cases should be also run on target machine to check potential errors, Then I want to introduce a sub package as VT suits. Purpose: UT: for developers, more likely a white box, running on building environment. VT: for user and deployment, more likely a black box, running on product or testing environment, all known issue should be covered.
Supposed approach: 1 modify building system to generate package: vdsm-VT.rpm.
I would prefer the package name 'vdsm-test.rpm' and this package should include unit tests and verification tests.
2 install as an option, after install, user type "vdsm-VT" would make the test begin.
The test runner should be able to run the full suite of unit tests and verification tests (with an option to run only unit tests or only verification tests). This can be the same program that we use in the build environment except that it will set the PYTHONPATH differently to target the installed files.
Planned details: 1 Going to place cases in vdsm project in ./tests/VT. 2 On installation will move some useful UT cases into VT.
If you follow my approach above, you would simply package the whole tests/ directory and no copying would be necessary.
3 use same framework UT used. 4 two sub dir in test/VT: user_case_test;general_test.
What is the difference between these two types of tests?
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
-- Shu Mingshuming@linux.vnet.ibm.com IBM China Systems and Technology Laboratory
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
On Thu, Apr 26, 2012 at 11:11:49AM -0500, Adam Litke wrote:
On Thu, Apr 26, 2012 at 11:12:06PM +0800, Shu Ming wrote:
One more comment about the test package version. Most likely, the package version will be the same version as the VDSM package version. The rule we need to consider is: Should we keep the back compatibility with the VDSM files? Say allow newer version test package running on older VDSM files? Or just allow run the same version of test package and VDSM package.One more comment about the test package version. Most likely, the package version will be the same version as the VDSM package version. The rule we need to consider is: Should we keep the back compatibility with the VDSM files? Say allow newer version test package running on older VDSM files? Or just allow run the same version of test package and VDSM package.
Backwards-compatible tests is not a good idea in my opinion. I would say that the test rpm should require the exact same vdsm version.
+1
于 2012-4-27 5:13, Ewoud Kohl van Wijngaarden 写道:
On Thu, Apr 26, 2012 at 11:11:49AM -0500, Adam Litke wrote:
On Thu, Apr 26, 2012 at 11:12:06PM +0800, Shu Ming wrote:
One more comment about the test package version. Most likely, the package version will be the same version as the VDSM package version. The rule we need to consider is: Should we keep the back compatibility with the VDSM files? Say allow newer version test package running on older VDSM files? Or just allow run the same version of test package and VDSM package.One more comment about the test package version. Most likely, the package version will be the same version as the VDSM package version. The rule we need to consider is: Should we keep the back compatibility with the VDSM files? Say allow newer version test package running on older VDSM files? Or just allow run the same version of test package and VDSM package.
Backwards-compatible tests is not a good idea in my opinion. I would say that the test rpm should require the exact same vdsm version.
+1
I guess it is the advantage to place test project inside vdsm project, they have major version synchronized always. User could get an older version with git reset.
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
On Fri, Apr 27, 2012 at 11:22:20AM +0800, wenchao xia wrote:
于 2012-4-27 5:13, Ewoud Kohl van Wijngaarden 写道:
On Thu, Apr 26, 2012 at 11:11:49AM -0500, Adam Litke wrote:
On Thu, Apr 26, 2012 at 11:12:06PM +0800, Shu Ming wrote:
One more comment about the test package version. Most likely, the package version will be the same version as the VDSM package version. The rule we need to consider is: Should we keep the back compatibility with the VDSM files? Say allow newer version test package running on older VDSM files? Or just allow run the same version of test package and VDSM package.One more comment about the test package version. Most likely, the package version will be the same version as the VDSM package version. The rule we need to consider is: Should we keep the back compatibility with the VDSM files? Say allow newer version test package running on older VDSM files? Or just allow run the same version of test package and VDSM package.
Backwards-compatible tests is not a good idea in my opinion. I would say that the test rpm should require the exact same vdsm version.
+1
I guess it is the advantage to place test project inside vdsm project, they have major version synchronized always. User could get an older version with git reset.
That's obviously simpler, and probably a good start.
As the project matures, it might become useful to see if an old vdsm satisfies newly-written tests, and someone may find it useful to test a remote vdsm. We can reconsider after we have "verfication tests".
于 2012-4-26 21:57, Adam Litke 写道:
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
Hello, vdsm now have UT suits for developer, but sometimes building and installation machine is not the same one, and additional check is need which is ignored at building time, so I think some test cases should be also run on target machine to check potential errors, Then I want to introduce a sub package as VT suits. Purpose: UT: for developers, more likely a white box, running on building environment. VT: for user and deployment, more likely a black box, running on product or testing environment, all known issue should be covered.
Supposed approach: 1 modify building system to generate package: vdsm-VT.rpm.
I would prefer the package name 'vdsm-test.rpm' and this package should include unit tests and verification tests.
2 install as an option, after install, user type "vdsm-VT" would make the test begin.
The test runner should be able to run the full suite of unit tests and verification tests (with an option to run only unit tests or only verification tests). This can be the same program that we use in the build environment except that it will set the PYTHONPATH differently to target the installed files.
good idea, checking on the details of vdsm-hack in tests.
Planned details: 1 Going to place cases in vdsm project in ./tests/VT. 2 On installation will move some useful UT cases into VT.
If you follow my approach above, you would simply package the whole tests/ directory and no copying would be necessary.
3 use same framework UT used. 4 two sub dir in test/VT: user_case_test;general_test.
What is the difference between these two types of tests?
user_cases would holds tests simulating the scenario user calling vdsm, and it could be examples for user. xmlrpc(vdscli) and rest-api cases would go here. I guess xmlrpc testcases already exist in engine side, and moving them here makes vdsm more independent and robust. general_test would holds test detecting target environment problem, such as authority settings, and thread pipe tests, etc. The names of the two directories are not good, need to be justified.
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
Yeah, plan to place the test in it.
As summary, I guess a better structure of test would be as following:
vdsm |--tests |test_runner.sh |--UT |--VT |--xmlrpc |--rest |--general
On Fri, Apr 27, 2012 at 11:19:21AM +0800, wenchao xia wrote:
于 2012-4-26 21:57, Adam Litke 写道:
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
Hello, vdsm now have UT suits for developer, but sometimes building and installation machine is not the same one, and additional check is need which is ignored at building time, so I think some test cases should be also run on target machine to check potential errors, Then I want to introduce a sub package as VT suits. Purpose: UT: for developers, more likely a white box, running on building environment. VT: for user and deployment, more likely a black box, running on product or testing environment, all known issue should be covered.
Supposed approach: 1 modify building system to generate package: vdsm-VT.rpm.
I would prefer the package name 'vdsm-test.rpm' and this package should include unit tests and verification tests.
2 install as an option, after install, user type "vdsm-VT" would make the test begin.
The test runner should be able to run the full suite of unit tests and verification tests (with an option to run only unit tests or only verification tests). This can be the same program that we use in the build environment except that it will set the PYTHONPATH differently to target the installed files.
good idea, checking on the details of vdsm-hack in tests.
Planned details: 1 Going to place cases in vdsm project in ./tests/VT. 2 On installation will move some useful UT cases into VT.
If you follow my approach above, you would simply package the whole tests/ directory and no copying would be necessary.
3 use same framework UT used. 4 two sub dir in test/VT: user_case_test;general_test.
What is the difference between these two types of tests?
user_cases would holds tests simulating the scenario user calling vdsm, and it could be examples for user. xmlrpc(vdscli) and rest-api cases would go here. I guess xmlrpc testcases already exist in engine side, and moving them here makes vdsm more independent and robust. general_test would holds test detecting target environment problem, such as authority settings, and thread pipe tests, etc. The names of the two directories are not good, need to be justified.
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
Yeah, plan to place the test in it.
As summary, I guess a better structure of test would be as following:
vdsm |--tests |test_runner.sh |--UT |--VT |--xmlrpc |--rest |--general
Sounds reasonable. But what's "general"? Isn't VT going to be using some kind of binding in any case? Oh, it might be a stupid comment, but I personally dislike upper case directory names. I find /ut/ /vt/ more modest.
Dan.
于 2012-4-30 17:26, Dan Kenigsberg 写道:
On Fri, Apr 27, 2012 at 11:19:21AM +0800, wenchao xia wrote:
于 2012-4-26 21:57, Adam Litke 写道:
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
Hello, vdsm now have UT suits for developer, but sometimes building and installation machine is not the same one, and additional check is need which is ignored at building time, so I think some test cases should be also run on target machine to check potential errors, Then I want to introduce a sub package as VT suits. Purpose: UT: for developers, more likely a white box, running on building environment. VT: for user and deployment, more likely a black box, running on product or testing environment, all known issue should be covered.
Supposed approach: 1 modify building system to generate package: vdsm-VT.rpm.
I would prefer the package name 'vdsm-test.rpm' and this package should include unit tests and verification tests.
2 install as an option, after install, user type "vdsm-VT" would make the test begin.
The test runner should be able to run the full suite of unit tests and verification tests (with an option to run only unit tests or only verification tests). This can be the same program that we use in the build environment except that it will set the PYTHONPATH differently to target the installed files.
good idea, checking on the details of vdsm-hack in tests.
Planned details: 1 Going to place cases in vdsm project in ./tests/VT. 2 On installation will move some useful UT cases into VT.
If you follow my approach above, you would simply package the whole tests/ directory and no copying would be necessary.
3 use same framework UT used. 4 two sub dir in test/VT: user_case_test;general_test.
What is the difference between these two types of tests?
user_cases would holds tests simulating the scenario user calling vdsm, and it could be examples for user. xmlrpc(vdscli) and rest-api cases would go here. I guess xmlrpc testcases already exist in engine side, and moving them here makes vdsm more independent and robust. general_test would holds test detecting target environment problem, such as authority settings, and thread pipe tests, etc. The names of the two directories are not good, need to be justified.
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
Yeah, plan to place the test in it.
As summary, I guess a better structure of test would be as following:
vdsm |--tests |test_runner.sh |--UT |--VT |--xmlrpc |--rest |--general
Sounds reasonable. But what's "general"? Isn't VT going to be using some kind of binding in any case?
planning to place some environment test case here, such as "thread and pipe test".
Oh, it might be a stupid comment, but I personally dislike upper case directory names. I find /ut/ /vt/ more modest.
OK, let's use lower case.
Dan.
On Wed, May 02, 2012 at 08:36:18AM +0800, wenchao xia wrote:
于 2012-4-30 17:26, Dan Kenigsberg 写道:
On Fri, Apr 27, 2012 at 11:19:21AM +0800, wenchao xia wrote:
于 2012-4-26 21:57, Adam Litke 写道:
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
Hello, vdsm now have UT suits for developer, but sometimes building and installation machine is not the same one, and additional check is need which is ignored at building time, so I think some test cases should be also run on target machine to check potential errors, Then I want to introduce a sub package as VT suits. Purpose: UT: for developers, more likely a white box, running on building environment. VT: for user and deployment, more likely a black box, running on product or testing environment, all known issue should be covered.
Supposed approach: 1 modify building system to generate package: vdsm-VT.rpm.
I would prefer the package name 'vdsm-test.rpm' and this package should include unit tests and verification tests.
2 install as an option, after install, user type "vdsm-VT" would make the test begin.
The test runner should be able to run the full suite of unit tests and verification tests (with an option to run only unit tests or only verification tests). This can be the same program that we use in the build environment except that it will set the PYTHONPATH differently to target the installed files.
good idea, checking on the details of vdsm-hack in tests.
Planned details: 1 Going to place cases in vdsm project in ./tests/VT. 2 On installation will move some useful UT cases into VT.
If you follow my approach above, you would simply package the whole tests/ directory and no copying would be necessary.
3 use same framework UT used. 4 two sub dir in test/VT: user_case_test;general_test.
What is the difference between these two types of tests?
user_cases would holds tests simulating the scenario user calling vdsm, and it could be examples for user. xmlrpc(vdscli) and rest-api cases would go here. I guess xmlrpc testcases already exist in engine side, and moving them here makes vdsm more independent and robust. general_test would holds test detecting target environment problem, such as authority settings, and thread pipe tests, etc. The names of the two directories are not good, need to be justified.
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
Yeah, plan to place the test in it.
As summary, I guess a better structure of test would be as following:
vdsm |--tests |test_runner.sh |--UT |--VT |--xmlrpc |--rest |--general
Sounds reasonable. But what's "general"? Isn't VT going to be using some kind of binding in any case?
planning to place some environment test case here, such as "thread and pipe test".
Why would you need a running Vdsm instance for such a test?
Dan.
于 2012-5-2 19:53, Dan Kenigsberg 写道:
On Wed, May 02, 2012 at 08:36:18AM +0800, wenchao xia wrote:
于 2012-4-30 17:26, Dan Kenigsberg 写道:
On Fri, Apr 27, 2012 at 11:19:21AM +0800, wenchao xia wrote:
于 2012-4-26 21:57, Adam Litke 写道:
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote:
Hello, vdsm now have UT suits for developer, but sometimes building and installation machine is not the same one, and additional check is need which is ignored at building time, so I think some test cases should be also run on target machine to check potential errors, Then I want to introduce a sub package as VT suits. Purpose: UT: for developers, more likely a white box, running on building environment. VT: for user and deployment, more likely a black box, running on product or testing environment, all known issue should be covered.
Supposed approach: 1 modify building system to generate package: vdsm-VT.rpm.
I would prefer the package name 'vdsm-test.rpm' and this package should include unit tests and verification tests.
2 install as an option, after install, user type "vdsm-VT" would make the test begin.
The test runner should be able to run the full suite of unit tests and verification tests (with an option to run only unit tests or only verification tests). This can be the same program that we use in the build environment except that it will set the PYTHONPATH differently to target the installed files.
good idea, checking on the details of vdsm-hack in tests.
Planned details: 1 Going to place cases in vdsm project in ./tests/VT. 2 On installation will move some useful UT cases into VT.
If you follow my approach above, you would simply package the whole tests/ directory and no copying would be necessary.
3 use same framework UT used. 4 two sub dir in test/VT: user_case_test;general_test.
What is the difference between these two types of tests?
user_cases would holds tests simulating the scenario user calling vdsm, and it could be examples for user. xmlrpc(vdscli) and rest-api cases would go here. I guess xmlrpc testcases already exist in engine side, and moving them here makes vdsm more independent and robust. general_test would holds test detecting target environment problem, such as authority settings, and thread pipe tests, etc. The names of the two directories are not good, need to be justified.
It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
Yeah, plan to place the test in it.
As summary, I guess a better structure of test would be as following:
vdsm |--tests |test_runner.sh |--UT |--VT |--xmlrpc |--rest |--general
Sounds reasonable. But what's "general"? Isn't VT going to be using some kind of binding in any case?
planning to place some environment test case here, such as "thread
and pipe test".
Why would you need a running Vdsm instance for such a test?
no need indeed, just want to find a place to holds test for generic issue. Maybe more check about the environment settings such as user vdsm/kvm authority check could also set here.(just an example, for now this test is not needed).
Dan.
On Wed, May 02, 2012 at 08:08:07PM +0800, wenchao xia wrote:
于 2012-5-2 19:53, Dan Kenigsberg 写道:
On Wed, May 02, 2012 at 08:36:18AM +0800, wenchao xia wrote:
于 2012-4-30 17:26, Dan Kenigsberg 写道:
On Fri, Apr 27, 2012 at 11:19:21AM +0800, wenchao xia wrote:
于 2012-4-26 21:57, Adam Litke 写道:
On Thu, Apr 26, 2012 at 05:24:29PM +0800, wenchao xia wrote: >Hello, > vdsm now have UT suits for developer, but sometimes building and >installation machine is not the same one, and additional check is need >which is ignored at building time, so I think some test cases should be >also run on target machine to check potential errors, Then I want to >introduce a sub package as VT suits. >Purpose: > UT: for developers, more likely a white box, running on building >environment. > VT: for user and deployment, more likely a black box, running on > product or testing environment, all known issue should be covered. > >Supposed approach: > 1 modify building system to generate package: vdsm-VT.rpm.
I would prefer the package name 'vdsm-test.rpm' and this package should include unit tests and verification tests.
> 2 install as an option, after install, user type "vdsm-VT" would make >the test begin.
The test runner should be able to run the full suite of unit tests and verification tests (with an option to run only unit tests or only verification tests). This can be the same program that we use in the build environment except that it will set the PYTHONPATH differently to target the installed files.
good idea, checking on the details of vdsm-hack in tests.
>Planned details: > 1 Going to place cases in vdsm project in ./tests/VT. > 2 On installation will move some useful UT cases into VT.
If you follow my approach above, you would simply package the whole tests/ directory and no copying would be necessary.
> 3 use same framework UT used. > 4 two sub dir in test/VT: user_case_test;general_test.
What is the difference between these two types of tests?
user_cases would holds tests simulating the scenario user calling vdsm, and it could be examples for user. xmlrpc(vdscli) and rest-api cases would go here. I guess xmlrpc testcases already exist in engine side, and moving them here makes vdsm more independent and robust. general_test would holds test detecting target environment problem, such as authority settings, and thread pipe tests, etc. The names of the two directories are not good, need to be justified.
> It is just a scratch from my mind, so I'd like hear your opinions.
Thanks for the idea! Do you have a sample test for the verification test suite? Will it be your pipe deadlock test?
Yeah, plan to place the test in it.
As summary, I guess a better structure of test would be as following:
vdsm |--tests |test_runner.sh |--UT |--VT |--xmlrpc |--rest |--general
Sounds reasonable. But what's "general"? Isn't VT going to be using some kind of binding in any case?
planning to place some environment test case here, such as "thread and pipe test".
Why would you need a running Vdsm instance for such a test?
no need indeed, just want to find a place to holds test for generic issue. Maybe more check about the environment settings such as user vdsm/kvm authority check could also set here.(just an example, for now this test is not needed).
Well, when the need rise, we can add more directories. Luckily git does not have empty dirs ;-)
vdsm-devel@lists.fedorahosted.org