Discuss tp-libvirt scripts support for python 2

[chunfuwen]

Everybody may know Python 2 End of Life is January 1st 2020.
I raise one issue for discussion, do we need still support python 2 in tp-libvirt scripts?
Anyone feel free to contribute your ideas?

[chunfuwen]

@balamuruhans
@kylazhang
@dzhengfy
@smitterl
@sathnaga

[balamuruhans]

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.

[sathnaga]

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,

[chunfuwen]

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

[smitterl]

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:

1. Tag py2-lts
2. 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
3. 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.