Comments (5)
@balamuruhans
@kylazhang
@dzhengfy
@smitterl
@sathnaga
from tp-libvirt.
Let's have a branch to support python2 similar to how we support avocado with 69lts
for python 2 and continue to have tp-libvirt master to support only python 3.
from tp-libvirt.
I guess most of the tests are already ported to python3, and we can create an item and work on remaining ones aswell, more over framework support for python3 is already there, now that all upcoming and old LTS distributions support both python2 and python3, is there any dependency or need for maintaining tests in python2?
Problem with having separate branch for python2 would be some one need to contribute and keep the branch sane, for all new test addition, which is unnecessary and additional effort.
So, my view is to focus only on python3 version of tests going forward, probably we can tag one old version which is known to work on python2 as py2-lts and leave it asis,
from tp-libvirt.
a few facts still need be considered if branch off python 2 version:
1)When we start branch off?
2)RHEL7 series releases still need use python 2, and RHEL 8 onwards release use python 3
3)If bug fix for test scripts is applied to python 2 ,suppose we need patch back, and how much efforts it could have?
4)We still have bunch of manual feature cases to be automated, which apply on both RHEL7 xx. and RHEL8 xx. That means we need push code changes to both branches
from tp-libvirt.
How is code compatibility handled so far? Do we have automated checks to discover version 2 or 3 incompatible code and do we merge these into master even if incompatible for one version?
I'd want to favor @sathnaga
So, my view is to focus only on python3 version of tests going forward, probably we can tag one old version which is known to work on python2 as py2-lts and leave it asis
However, @chunfuwen mentions RHEL 7 requires Python 2
3)If bug fix for test scripts is applied to python 2 ,suppose we need patch back, and how much efforts it could have?
4)We still have bunch of manual feature cases to be automated, which apply on both RHEL7 xx. and RHEL8 xx. That means we need push code changes to both branches
I'm wondering therefore if a possible path forward can be:
- Tag py2-lts
- All new code must be both 2 and 3 compatible, e.g. Cheat Sheet: Writing Python 2-3 compatible code; enforce and communicate this with some guidance
- When RHEL 7 test support ends, tag py2-lts-end and only accept 3 compatible code
(2.) is essentially strategy "Python 2 and Python 3 without conversion" from http://python3porting.com/strategies.html. In order to achieve this we can add to README the info to use 2to3
tool to help guide making the code compatible for both versions. In any case, for me (2.) must be enforced by some tool in the ci.
from tp-libvirt.
Related Issues (20)
- Enchance PoolVolumeTest class
- Freeze utils_test/libvirt.py HOT 2
- create one common ceph_utils to cover ceph related preparation function
- Enable the test for transient disk
- About the usage of test.error()/test.fail()/test.cancel() HOT 1
- Fix false failure of virtual_disks.multidisks.coldplug.single_disk_test.disk_bus_device_option.disk_bus_usb.device_disk.error_test4
- Discuss where to put helper function in python file, within run() or same level of run()? HOT 14
- Remove the cases of ceph none authorization
- RFE: support rotation_rate for IDE/SCSI/SATA disks HOT 1
- Don't use /tmp for disk attach
- Add guest internal read/write checking for cases virsh.migrate_storage.*
- Close pull request created more than two years old HOT 1
- Enable spell check in CI workflow HOT 4
- Fix the copy failed issue of virtual_disks.ceph.hot_plug.with_auth.default.rbd_blockcopy.slices_reuse_external HOT 4
- Root logger is not avilible to avocado tests after the 92.0 LTS HOT 4
- Discuss whether we introduce metrics or Telemetry concept . If we have, what are the clear scope definition for this HOT 1
- Nested vm
- prepare_attached_device() missing 1 required positional argument: 'device'
- How to use option enable-kvm for virt-install
- Iscsi disk size for saving the guest state is insufficient!
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tp-libvirt.