[openstack-dev] [all][tc][ptls] final stages of python 3 transition

Andrey Pavlov andrey.mp at gmail.com
Mon Apr 30 17:40:07 UTC 2018


Hi Doug,

There is no ec2-api project on the link.
But we have voted job  openstack-tox-py35
<http://logs.openstack.org/85/552085/2/check/openstack-tox-py35/6464ed8/>

Regards,
Andrey Pavlov.

On Mon, Apr 30, 2018 at 6:06 PM, Doug Hellmann <doug at doughellmann.com>
wrote:

> It would be useful to have more input from PTLs on this issue, so I'm
> CCing all of them to get their attention.
>
> Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:
> > It's time to talk about the next steps in our migration from python
> > 2 to python 3.
> >
> > Up to this point we have mostly focused on reaching a state where
> > we support both versions of the language. We are not quite there
> > with all projects, as you can see by reviewing the test coverage
> > status information at
> > https://wiki.openstack.org/wiki/Python3#Python_3_Status_
> of_OpenStack_projects
> >
> > Still, we need to press on to the next phase of the migration, which
> > I have been calling "Python 3 first". This is where we use python
> > 3 as the default, for everything, and set up the exceptions we need
> > for anything that still requires python 2.
> >
> > To reach that stage, we need to:
> >
> > 1. Change the documentation and release notes jobs to use python 3.
> >    (The Oslo team recently completed this, and found that we did
> >    need to make a few small code changes to get them to work.)
> > 2. Change (or duplicate) all functional test jobs to run under
> >    python 3.
> > 3. Change the packaging jobs to use python 3.
> > 4. Update devstack to use 3 by default and require setting a flag to
> >    use 2. (This may trigger other job changes.)
> >
> > At that point, all of our deliverables will be produced using python
> > 3, and we can be relatively confident that if we no longer had
> > access to python 2 we could still continue operating. We could also
> > start updating deployment tools to use either python 3 or 2, so
> > that users could actually deploy using the python 3 versions of
> > services.
> >
> > Somewhere in that time frame our third-party CI systems will need
> > to ensure they have python 3 support as well.
> >
> > After the "Python 3 first" phase is completed we should release
> > one series using the packages built with python 3. Perhaps Stein?
> > Or is that too ambitious?
> >
> > Next, we will be ready to address the prerequisites for "Python 3
> > only," which will allow us to drop Python 2 support.
> >
> > We need to wait to drop python 2 support as a community, rather
> > than going one project at a time, to avoid doubling the work of
> > downstream consumers such as distros and independent deployers. We
> > don't want them to have to package all (or even a large number) of
> > the dependencies of OpenStack twice because they have to install
> > some services running under python 2 and others under 3. Ideally
> > they would be able to upgrade all of the services on a node together
> > as part of their transition to the new version, without ending up
> > with a python 2 version of a dependency along side a python 3 version
> > of the same package.
> >
> > The remaining items could be fixed earlier, but this is the point
> > at which they would block us:
> >
> > 1. Fix oslo.service functional tests -- the Oslo team needs help
> >    maintaining this library. Alternatively, we could move all
> >    services to use cotyledon (https://pypi.org/project/cotyledon/).
> >
> > 2. Finish the unit test and functional test ports so that all of
> >    our tests can run under python 3 (this implies that the services
> >    all run under python 3, so there is no more porting to do).
> >
> > Finally, after we have *all* tests running on python 3, we can
> > safely drop python 2.
> >
> > We have previously discussed the end of the T cycle as the point
> > at which we would have all of those tests running, and if that holds
> > true we could reasonably drop python 2 during the beginning of the
> > U cycle, in late 2019 and before the 2020 cut-off point when upstream
> > python 2 support will be dropped.
> >
> > I need some info from the deployment tool teams to understand whether
> > they would be ready to take the plunge during T or U and start
> > deploying only the python 3 version. Are there other upgrade issues
> > that need to be addressed to support moving from 2 to 3? Something
> > that might be part of the platform(s), rather than OpenStack itself?
> >
> > What else have I missed in these phases? Other jobs? Other blocking
> > conditions?
> >
> > Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180430/d05856fb/attachment.html>


More information about the OpenStack-dev mailing list