Austin, Can you add one more column in your xls sheet: https://bugs.launchpad.net/starlingx/+bug/1808073/+attachment/5274592/+files...: In your column "I", for your "3rd party" category, to break down "CentOS package" & "3rd party package", so that we can understand how much we can rely on CentOS 8.0, especially for those "risk" ones. Thanks. - cindy -----Original Message----- From: Yong Hu [mailto:yong.hu@intel.com] Sent: Thursday, July 4, 2019 11:25 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python2 -> Python3 A general question, do we have experience and confidence to ensure 2 python versions (both interpreters and pip libs) can co-exist and each of packages can correctly refer to them?? In my view the best solution is to wait for CentOS 8.0 :-) On 03/07/2019 2:55 PM, Dean Troyer wrote:
On 7/3/19 4:07 PM, Saul Wold wrote:
The current proposal seems to be to completely convert the base CentOS7.6 system level python to use python3, this carries a high risk factor as changing out all system-level python code could have a cascade effect on system functionality and additional dependencies. While
Changing the distro/system Python version out from under the rest of the distro seems like an enormous time sink, much less a significant reliability risk.
A better solution would be to build python3 and the associated requirements from the existing RHEL EPEL (Extra Packages for Enterprise Linux) Source RPMs repo and install them into the ISO. This version correctly installs in a segregated directory tree.
We would probably want to run a significant subset of the upstream OpenStack testing on this combination as it is not (AFAIK) tested there. But this is true of any runtime + distro combination that is not in the fairly short list of combinations that upstream OpenStack actively tests.
Another option would be to delay the actual python2 conversion to StarlingX 4.0, the OpenStack Train release will still support python2.
One downside to this is it leaves us no margin to defer the change again, this is our second chance as it were. OpenStack U (as of now) is likely to drop py2 support as a guarantee across-the-board.
There is still work that is needed beyond the conversion of the python code itself to things like RPM specfiles data and other source code (such as, C code that has #includes of python2.7). It's not clear to me how much functional testing with python3 has occurred for the flock beyond what Dean has started with devstack.
I managed to get the fault services running on py3, sysinv fell over during the dbsync in my quick post-PTG trial run. That is as far as I took it. Anyone who wants to try can pick out the local.conf I posted [0]
dt
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss