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
>> There's no py3 available in RHEL 7.
>> The alternative to making things work in Fedora is to use Software
>> Collections .
>> 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
>> 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  or the official docs for SCL .
> 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
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.
>> 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
>> Most of the hard work for Fedora is already done as far as packaging
>> is concerned, we never really stopped building packages for Fedora
>> It means we should be prepared once RHEL 8 comes out.
>> : https://www.softwarecollections.org/en/
>> : 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)