I think I can use this module in place of the rpm one: https://pypi.org/project/version_utils/ It looks like this provides an equivalent to rpm.labelCompare that should allow me to drop rpm-python. -----Original Message----- From: Penney, Don Sent: Thursday, July 11, 2019 3:50 PM To: 'Saul Wold'; starlingx-discuss@lists.starlingx.io Subject: RE: [Starlingx-discuss] Python2 -> Python3 It probably makes sense for me to look at moving the patching framework from "smart" back to "yum" - and at the same, restructure the code so that package management is a backend. It was originally written with yum many years ago, then moved to "smart" to align with yocto. We can also look at upversioning requests-toolbelt - we're on an older version solely because there's never been a reason to update it. That said, the version we're using, 0.5.1, is in pypi as py2.py3, so presumably that's ok? I can also look at the current use of the rpm module in patching and look for alternatives. -----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Thursday, July 11, 2019 3:40 PM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python2 -> Python3 On 7/10/19 7:03 AM, Sun, Austin wrote:
Hi All: The logical for here is if package from centos directly , we will wait upgrading to CentOS 8.x to compliance with python3 Please filter 'Do not contain centos' in Column N , then it will show below 11 packages. As sync in non-OpenStack distro meeting. We still can filter out the 4 packages from fedora project and python-cephclient as flock servers . So below 6 packages are coming 3rd party which might be not python2to3 compliance.
Package | who is using openvswitch | ovs python-cephfs | ceph python-smartpm | standalone package qemu-kvm-ev | mtce-compute requests-toolbelt | cgcs-patch-controller rpm-python | cgcs-patch-controller
Can you identify replacement python3 packages for any of these. I know we found out that smartpm is used for the patch process, I know that smartpm is also an older project that does not have any upstream support any further, so that will require a fair amount of work. Sau!
Thanks. BR Austin Sun.
-----Original Message----- From: Sun, Austin [mailto:austin.sun@intel.com] Sent: Wednesday, July 10, 2019 4:03 PM To: Xie, Cindy <cindy.xie@intel.com>; Hu, Yong <yong.hu@intel.com>; 'starlingx-discuss@lists.starlingx.io' <starlingx-discuss@lists.starlingx.io> Subject: Re: [Starlingx-discuss] Python2 -> Python3
Hi All: New sheet was updated to [1]. Adding column N (repo_info) to record where the package coming from. There are 11 packages not from centos but including python and may not be compatiable python2 and python3. Package | who is using openvswitch | ovs python-aniso8601 | keystone python-cephclient | ceph python-cephfs | ceph python-django-bash-completion | sysinv python-smartpm | standalone package python-unittest2 | sysinv python-XStatic-jquery-ui | stx-gui qemu-kvm-ev | mtce-compute requests-toolbelt | cgcs-patch-controller rpm-python | cgcs-patch-controller
I will continue check those 11 packages .
[1] https://bugs.launchpad.net/starlingx/+bug/1808073
Thanks. BR Austin Sun.
-----Original Message----- From: Sun, Austin Sent: Thursday, July 4, 2019 11:43 AM To: Xie, Cindy <cindy.xie@intel.com>; Hu, Yong <yong.hu@intel.com>; starlingx-discuss@lists.starlingx.io Subject: RE: [Starlingx-discuss] Python2 -> Python3
Hi Cindy: Yes. we will do it and update sheet.
Thanks. BR Austin Sun.
-----Original Message----- From: Xie, Cindy [mailto:cindy.xie@intel.com] Sent: Thursday, July 4, 2019 11:37 AM To: Hu, Yong <yong.hu@intel.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Python2 -> Python3
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 _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss