2018-02-14 17:05 GMT+01:00 Ben Nemec <openst...@nemebean.com>: > > > On 02/13/2018 05:30 PM, David Moreau Simard wrote: >> >> On Tue, Feb 13, 2018 at 5:53 PM, Ben Nemec <openst...@nemebean.com> wrote: >>> >>> >>> I guess if RDO has chosen this path then we don't have much choice. >> >> >> This makes it sound like we had a choice to begin with. >> We've already had a lot of discussions around the topic but we're >> ultimately stuck between a rock and a hard place. >> >> We're in this together and it's important that everyone understands >> what's going on. >> >> It's not a secret to anyone that Fedora is more or less the upstream to >> RHEL. >> There's no py3 available in RHEL 7. >> The alternative to making things work in Fedora is to use Software >> Collections [1]. >> >> If you're not familiar with Software Collections for python, it's more >> or less the installation of RPM packages in a virtualenv. >> Installing the "rh-python35" SCL would: >> - Set up a chroot in /opt/rh/rh-python35/root >> - Set up a py35 interpreter at /opt/rh/rh-python35/root/usr/bin/python3 >> >> And then, when you would install packages *against* that SCL, they >> would end up being installed >> in /opt/rh/rh-python35/root/usr/lib/python3.5/site-packages/. >> >> That means that you need *all* of your python packages to be built >> against the software collections and installed in the right path. >> >> Python script with a #!/usr/bin/python shebang ? Probably not going to >> work. >> Need python-requests ? Nope, sclo-python35-python-requests. >> Need one of the 1000+ python packages maintained by RDO ? >> Those need to be re-built and maintained against the SCL too. >> >> If you want to see what it looks like in practice, here's a Zuul spec >> file [2] or the official docs for SCL [3]. > > > Ick, I didn't realize SCLs were that bad. >
And that's only the tip of the iceberg :) > /me dons his fireproof suit > > I know this is a dirty word around these parts, but I note that EPEL appears > to have python 3 packages... > All I can say is that option was put on the table. > Ultimately, though, I'm not in a position to be making any definitive > statements about how to handle this. RDO has more consumers than just > TripleO. The purpose of my email was mostly to provide some historical > perspective from back when we were doing TripleO CI on Fedora, why we're not > doing that anymore, and in fact went so far as to explicitly disable Fedora > in the undercloud installer. If Fedora is still our best option then so be > it, but I don't want anyone to think it's going to be as simple as > s/CentOS/Fedora/ (I assume no one does, but you know what they say about > ass-u-me :-). > I agree it won't be simple, we will have to provide those repositories, determine how we will gate updates, fix puppet modules, POI, etc.. and that's only a beginning. That's why we won't be providing raw Fedora but rather a curated version and at some point, we'll likely freeze it. That's kinda similar to how EL8 is made, but it won't be EL8. :o) Let's say that the time is ticking, if we want to ship a productized OpenStack distro on Python3, and possibly on EL8 (Hint: I don't know when it will be released, and moreover, I'm not the one who gets to decide when RHOSP will support EL8), we're about to reach the point of no-return. H. > >> >> Making stuff work on Fedora is not going to be easy for anyone but it >> sure beats messing with 1500+ packages that we'd need to untangle >> later. >> Most of the hard work for Fedora is already done as far as packaging >> is concerned, we never really stopped building packages for Fedora >> [4]. >> >> It means we should be prepared once RHEL 8 comes out. >> >> [1]: https://www.softwarecollections.org/en/ >> [2]: >> https://softwarefactory-project.io/r/gitweb?p=scl/zuul-distgit.git;a=blob;f=zuul.spec;h=6bba6a79c1f8ff844a9ea3715ab2cef1b12d323f;hb=refs/heads/master >> [3]: >> https://www.softwarecollections.org/en/docs/guide/#chap-Packaging_Software_Collections >> [4]: https://trunk.rdoproject.org/fedora-rawhide/report.html >> >> David Moreau Simard >> Senior Software Engineer | OpenStack RDO >> >> dmsimard = [irc, github, twitter] >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
