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.

/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...

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 :-).


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

Reply via email to