Open Stack

2018-02-14 17:05 GMT+01:00 Ben Nemec <openstack at nemebean.com>:
>
>
> On 02/13/2018 05:30 PM, David Moreau Simard wrote:
>>
>> On Tue, Feb 13, 2018 at 5:53 PM, Ben Nemec <openstack at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev