<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">I'll take a look at these today Alex.</div><div class="gmail_default" style="font-family:verdana,sans-serif">Mark</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 Mar 2019 at 15:16, Alex Schultz <<a href="mailto:aschultz@redhat.com">aschultz@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Mar 1, 2019 at 2:47 AM Mark Goddard <<a href="mailto:mark@stackhpc.com" target="_blank">mark@stackhpc.com</a>> wrote:<br>
><br>
> Thanks for getting this conversation going.<br>
><br>
> On Thu, 28 Feb 2019 at 19:46, Marcin Juszkiewicz <<a href="mailto:marcin.juszkiewicz@linaro.org" target="_blank">marcin.juszkiewicz@linaro.org</a>> wrote:<br>
>><br>
>> Python 2 is going bye bye. Everyone knows that, lot of us ignores that.<br>
>> But we need to move on.<br>
><br>
><br>
> *pulls head out of sand*<br>
>><br>
>><br>
>> Kolla has few patches to make use of Python3 based binary packages. One<br>
>> for Fedora [1], other for Ubuntu and Debian [2].<br>
>><br>
>> 1. <a href="https://review.openstack.org/624838" rel="noreferrer" target="_blank">https://review.openstack.org/624838</a><br>
>> 2. <a href="https://review.openstack.org/625298" rel="noreferrer" target="_blank">https://review.openstack.org/625298</a><br>
><br>
><br>
> There is also the python3 on RHEL8 patch: <a href="https://review.openstack.org/#/c/632156/19" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/632156/19</a>.<br>
<br>
Just to raise this up again, but would it be possible to try and land<br>
<a href="https://review.openstack.org/#/c/632156/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/632156/</a> and<br>
<a href="https://review.openstack.org/#/c/639219/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/639219/</a>. We'd really like to get a<br>
head start on the python3 testing as we've got some python3 packages<br>
for fedora & stein.<br>
<br>
>><br>
>><br>
>><br>
>> But those patches are just tip of iceberg...<br>
>><br>
>> # Types of images<br>
>><br>
>> There are two types of images in Kolla:<br>
>><br>
>> - binary<br>
>> - source<br>
>><br>
>> ## Binaries state in distributions<br>
>><br>
>> Binary ones are built from distribution packages. For<br>
>> RHEL/CentOS/OracleLinux is means RDO packages, for Ubuntu it is UCA and<br>
>> for Debian it is whatever is in distribution repositories.<br>
>><br>
>> RDO ones are Python 2 based because there is no other version of Python<br>
>> in RHEL7 (I do not count EPEL or SCL).<br>
><br>
><br>
> Although RHEL8 is python 3 only.<br>
><br>
>><br>
>> For Ubuntu we have a mix of Python 2 and Python 3 (from what I heard).<br>
>><br>
>> Debian needs update to Buster (current 'testing', currently in soft<br>
>> freeze) and then we will get Python 3 packages (currently for Rocky).<br>
>><br>
>> ### Pip issue<br>
>><br>
>> On binary distributions we tend to use 'pip' from distribution packages.<br>
>> Which means 8.1.2 for CentOS:7, 9.0.1 for Ubuntu:bionic and 18.1 for<br>
>> Debian:buster.<br>
>><br>
><br>
> For binary images we don't typically use pip, right - so this is just for edge cases where a package isn't available?<br>
><br>
>><br>
>><br>
>> ## Source images<br>
>><br>
>> In my opinion this type of images is most common during development cycle.<br>
>><br>
> People use them in production too - better for CI/CD, or if you have downstream patches.<br>
><br>
>><br>
>> Here we install Python and binaries from distribution repositories and<br>
>> then bootstrap latest 'pip' and use it to install all Python modules we<br>
>> need.<br>
>><br>
>> For now those images are Python 2 based.<br>
>><br>
>><br>
>> # WIP plans for T cycle<br>
>><br>
>> For T cycle we should move whatever possible to Python 3. Which means<br>
>> Debian:buster, Ubuntu:bionic and source images. No idea yet does it<br>
>> involves CentOS:7 source images as well as this would require us to use<br>
>> EPEL repository for Python 3.<br>
>><br>
><br>
> As Jeremy suggests, I think we may need to support both in some cases. That may not be possible for binary images - we can only use what is offered by distros - but for source images there's no reason (AFAIK) why we can't have a config option for the version of python to use. We now [1] have a distro_python3 config flag that does this. In hindsight, 'distro' might not be the most appropriate name for source images, but hey.<br>
><br>
>> ## Always bootstrap pip<br>
>><br>
>> Due to 'pip' issue we may need to bootstrap latest version in each type<br>
>> of images. This will give us simple 'pip' command in each image<br>
>> nevermind which version of Python is used. That saves us from dealing<br>
>> with "is it 'pip' or 'pip3' we need to use" thing.<br>
>><br>
><br>
> Although that question is fairly trivial if there is a config option for the python version.<br>
><br>
> I think Martin Andre would have an issue with this, given his recent work on trying to evict non-distro stuff from binary images.<br>
>><br>
>> ## Create new variables<br>
>><br>
>> There will be few different versions of Python in use: 2.7 (RHEL7<br>
>> family), 3.6 (Ubuntu:bionic and RHEL7/EPEL), 3.7 (Debian:buster). As we<br>
>> tend to modify some files or need to know where Python modules are<br>
>> present. We may use values from 'sys.path' list for it or create<br>
>> 'python_path' (or similar) variable and set it per distribution/image_type.<br>
>><br>
> Also, RHEL8/CentOS8 will be 3.6, Fedora 28 is 3.7?<br>
><br>
>><br>
>> # Some kind of work items list<br>
>><br>
>> 1. Move Debian to 'buster' release. <a href="https://review.openstack.org/612681" rel="noreferrer" target="_blank">https://review.openstack.org/612681</a><br>
>> 2. Bootstrap 'pip' in all image types.<br>
>> 3. Move source images to Python 3 (Debian, Ubuntu for sure, no idea yet<br>
>>    about CentOS).<br>
><br>
><br>
> s/Move/Add support for/<br>
><br>
>><br>
>> 4. Move binary images to Python 3 (Debian, Ubuntu, Fedora/RHEL8)<br>
>><br>
>> Each step will require several build/test/fix cycles. We also need to<br>
>> identify which images still require Python 2.<br>
>><br>
><br>
> Time for a big table.<br>
><br>
>><br>
>> # Summary<br>
>><br>
>> I know that this mail looks a bit chaotic but I think that we need to<br>
>> discuss and plan what we need to do and how. And cooperate with external<br>
>> teams which provide binary packages (that's why Thomas and Haïkel are in<br>
>> Cc:).<br>
>><br>
>> What do you think?<br>
<br>
</blockquote></div>