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

[Doug Hellmann]

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


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.or

[Jeremy Stanley]

On 2018-04-25 16:54:46 -0400 (-0400), Doug Hellmann wrote:
[...]

Post by Doug Hellmann
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.

[...]

It may be worth considering how this interacts with the switch of
our default test platform from Ubuntu 16.04 (which provides Python
3.5) to 18.04 (which provides Python 3.6). If we switch from 3.5 to
3.6 before we change most remaining jobs over to Python 3.x versions
then it gives us a chance to spot differences between 3.5 and 3.6 at
that point. Given that the 14.04 to 16.04 migration, where we
attempted to allow projects to switch at their own pace, didn't go
so well we're hoping to do a "big bang" migration instead for 18.04
and expect teams who haven't set up experimental jobs ahead of time
to work out remaining blockers after the flag day before they can go
back to business as usual. Since the 18.04 release is happening so
far into the Rocky cycle, we're likely to want to do that at the
start of Stein instead when it will be less disruptive.

So I guess that raises the question: switch to Python 3.5 by default
for most jobs in Rocky and then have a potentially more disruptive
default platform switch with Python 3.5->3.6 at the beginning of
Stein, or wait until the default platform switch to move from Python
2.7 to 3.6 as the job default? I can see some value in each option.

[Doug Hellmann]

Post by Jeremy Stanley
[...]

Post by Doug Hellmann
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.

[...]
It may be worth considering how this interacts with the switch of
our default test platform from Ubuntu 16.04 (which provides Python
3.5) to 18.04 (which provides Python 3.6). If we switch from 3.5 to
3.6 before we change most remaining jobs over to Python 3.x versions
then it gives us a chance to spot differences between 3.5 and 3.6 at
that point. Given that the 14.04 to 16.04 migration, where we
attempted to allow projects to switch at their own pace, didn't go
so well we're hoping to do a "big bang" migration instead for 18.04
and expect teams who haven't set up experimental jobs ahead of time
to work out remaining blockers after the flag day before they can go
back to business as usual. Since the 18.04 release is happening so
far into the Rocky cycle, we're likely to want to do that at the
start of Stein instead when it will be less disruptive.
So I guess that raises the question: switch to Python 3.5 by default
for most jobs in Rocky and then have a potentially more disruptive
default platform switch with Python 3.5->3.6 at the beginning of
Stein, or wait until the default platform switch to move from Python
2.7 to 3.6 as the job default? I can see some value in each option.

Does 18.04 include a python 2 option?

What is the target for completing the changeover? The first or
second milestone for Stein, or the end of the cycle?

It would be useful to have some input from the project teams who
have no unit or functional test jobs running for 3.5, since they
will have the most work to do to cope with the upgrade overall.

Who is coordinating Ubuntu upgrade work and setting up the experimental
jobs?

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailm

[Clark Boylan]

Post by Doug Hellmann

Post by Jeremy Stanley
[...]

Post by Doug Hellmann
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.

[...]
It may be worth considering how this interacts with the switch of
our default test platform from Ubuntu 16.04 (which provides Python
3.5) to 18.04 (which provides Python 3.6). If we switch from 3.5 to
3.6 before we change most remaining jobs over to Python 3.x versions
then it gives us a chance to spot differences between 3.5 and 3.6 at
that point. Given that the 14.04 to 16.04 migration, where we
attempted to allow projects to switch at their own pace, didn't go
so well we're hoping to do a "big bang" migration instead for 18.04
and expect teams who haven't set up experimental jobs ahead of time
to work out remaining blockers after the flag day before they can go
back to business as usual. Since the 18.04 release is happening so
far into the Rocky cycle, we're likely to want to do that at the
start of Stein instead when it will be less disruptive.
So I guess that raises the question: switch to Python 3.5 by default
for most jobs in Rocky and then have a potentially more disruptive
default platform switch with Python 3.5->3.6 at the beginning of
Stein, or wait until the default platform switch to move from Python
2.7 to 3.6 as the job default? I can see some value in each option.

Does 18.04 include a python 2 option?

It does, https://packages.ubuntu.com/bionic/python2.7.

Post by Doug Hellmann
What is the target for completing the changeover? The first or
second milestone for Stein, or the end of the cycle?

Previously we've tried to do the transition in OpenStack release that is under development when the LTS releases. However we've offset things a bit now so that may not be as feasible. I would expect that if we waited for the next cycle we would do it very early in that cycle.

For the transition from python 3.5 on Xenial to 3.6 on Bionic we may want to keep the python 3.5 jobs on Xenial but add in non voting python 3.6 jobs to every project running Xenial python3.5 jobs. Then those projects can toggle them to voting 3.6 jobs if/when they start working. Then we can decide at a later time if continuing to support python 3.5 (and testing it) is worthwhile.

Post by Doug Hellmann
It would be useful to have some input from the project teams who
have no unit or functional test jobs running for 3.5, since they
will have the most work to do to cope with the upgrade overall.
Who is coordinating Ubuntu upgrade work and setting up the experimental
jobs?

Paul Belanger has been doing much of the work to get the images up and running and helping some projects start to run early jobs on the beta images. I expect Paul would want to continue to carry the transition through to the end.

Clark

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/

[Jeremy Stanley]

On 2018-04-25 18:25:24 -0400 (-0400), Doug Hellmann wrote:
[...]

Post by Doug Hellmann
Does 18.04 include a python 2 option?

Yes, 2.7.15 if packages.ubuntu.com is to be believed.

Post by Doug Hellmann
What is the target for completing the changeover? The first or
second milestone for Stein, or the end of the cycle?

I would expect us to want to pull the trigger after whatever grace
period the cycle-trailing projects are comfortable with (but
certainly before the first milestone I would think?).

Post by Doug Hellmann
It would be useful to have some input from the project teams who
have no unit or functional test jobs running for 3.5, since they
will have the most work to do to cope with the upgrade overall.

Yes, it would in my opinion anyway.

Post by Doug Hellmann
Who is coordinating Ubuntu upgrade work and setting up the
experimental jobs?

We have preliminary ubuntu-bionic images available already
(officially it doesn't release until tomorrow), and some teams have
started to use them for experimental or non-voting jobs:

http://codesearch.openstack.org/?q=ubuntu-bionic

[Thomas Goirand]

Post by Jeremy Stanley
It may be worth considering how this interacts with the switch of
our default test platform from Ubuntu 16.04 (which provides Python
3.5) to 18.04 (which provides Python 3.6). If we switch from 3.5 to
3.6 before we change most remaining jobs over to Python 3.x versions
then it gives us a chance to spot differences between 3.5 and 3.6 at
that point.

I don't think you'll find lots of issues, as all Debian and Gentoo
packages were built against Python 3.6, and hopefully, prometheanfire
and myself have reported the issues.

Post by Jeremy Stanley
So I guess that raises the question: switch to Python 3.5 by default
for most jobs in Rocky and then have a potentially more disruptive
default platform switch with Python 3.5->3.6 at the beginning of
Stein, or wait until the default platform switch to move from Python
2.7 to 3.6 as the job default? I can see some value in each option.

I'd love to see gating on both Python 3.5 and 3.6 if possible.

Also, can we restart the attempts (non-voting) gating jobs with Debian
Sid? That's always were we get all updates first.

Cheers,

Thomas Goirand (zigo)

[Sean McGinnis]

Post by Doug Hellmann
It's time to talk about the next steps in our migration from python
2 to python 3.
[...]
2. Change (or duplicate) all functional test jobs to run under
python 3.

As a test I ran Cinder functional and unit test jobs on bionic using 3.6. All
went well.

That made me realize something though - right now we have jobs that explicitly
say py35, both for unit tests and functional tests. But I realized setting up
these test jobs that it works to just specify "basepython = python3" or run
unit tests with "tox -e py3". Then with that, it just depends on whether the
job runs on xenial or bionic as to whether the job is run with py35 or py36.

It is less explicit, so I see some downside to that, but would it make sense to
change jobs to drop the minor version to make it more flexible and easy to make
these transitions?

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org

[Paul Belanger]

Post by Sean McGinnis

Post by Doug Hellmann
It's time to talk about the next steps in our migration from python
2 to python 3.
[...]
2. Change (or duplicate) all functional test jobs to run under
python 3.

As a test I ran Cinder functional and unit test jobs on bionic using 3.6. All
went well.
That made me realize something though - right now we have jobs that explicitly
say py35, both for unit tests and functional tests. But I realized setting up
these test jobs that it works to just specify "basepython = python3" or run
unit tests with "tox -e py3". Then with that, it just depends on whether the
job runs on xenial or bionic as to whether the job is run with py35 or py36.
It is less explicit, so I see some downside to that, but would it make sense to
change jobs to drop the minor version to make it more flexible and easy to make
these transitions?

I still think using tox-py35 / tox-py36 makes sense, as those jobs are already
setup to use the specific nodeset of ubuntu-xenial or ubuntu-bionic. If we did
move to just tox-py3, it would actually result if more code projects would need
to add to their .zuul.yaml files:

-project:
check:
jobs:
- tox-py35


-project:
check:
jobs:
- tox-py3:
nodeset: ubuntu-xenial

This maybe okay, will allow others to comment, but the main reason I am not a
fan, is we can no longer infer the nodeset by looking at the job name.
tox-py3 could be xenial or bionic.

Paul

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/

[Jeremy Stanley]

On 2018-04-26 13:17:33 -0400 (-0400), Paul Belanger wrote:
[...]

Post by Paul Belanger
This maybe okay, will allow others to comment, but the main reason
I am not a fan, is we can no longer infer the nodeset by looking
at the job name. tox-py3 could be xenial or bionic.

This brings back a question we've struggled with for years: are we
testing against "Python X.Y" or are we testing against "Python as
provided by distro Z"? Depending on how you think about that, one
solution or the other is technically a more accurate reflection of
our choice here.

[Clark Boylan]

Post by Sean McGinnis

Post by Doug Hellmann
It's time to talk about the next steps in our migration from python
2 to python 3.
[...]
2. Change (or duplicate) all functional test jobs to run under
python 3.

As a test I ran Cinder functional and unit test jobs on bionic using 3.6. All
went well.
That made me realize something though - right now we have jobs that explicitly
say py35, both for unit tests and functional tests. But I realized setting up
these test jobs that it works to just specify "basepython = python3" or run
unit tests with "tox -e py3". Then with that, it just depends on whether the
job runs on xenial or bionic as to whether the job is run with py35 or py36.
It is less explicit, so I see some downside to that, but would it make sense to
change jobs to drop the minor version to make it more flexible and easy to make
these transitions?

One reason to use it would be local user simplicity. Rather than need to explicitly add new python3 releases to the default env list so that it does what we want every year or two we can just list py3,py2,linters in the default list and get most of the way there for local users. Then we can continue to be more specific in the CI jobs if that is desirable.

I do think we likely want to be explicit about the python versions we are using in CI testing. This makes it clear to developers who may need to reproduce or just understand why failures happen what platform is used. It also makes it explicit that "openstack runs on $pythonversion".

Clark

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openst

[Doug Hellmann]

Post by Clark Boylan

Post by Sean McGinnis

Post by Doug Hellmann
It's time to talk about the next steps in our migration from python
2 to python 3.
[...]
2. Change (or duplicate) all functional test jobs to run under
python 3.

As a test I ran Cinder functional and unit test jobs on bionic using 3.6. All
went well.
That made me realize something though - right now we have jobs that explicitly
say py35, both for unit tests and functional tests. But I realized setting up
these test jobs that it works to just specify "basepython = python3" or run
unit tests with "tox -e py3". Then with that, it just depends on whether the
job runs on xenial or bionic as to whether the job is run with py35 or py36.
It is less explicit, so I see some downside to that, but would it make sense to
change jobs to drop the minor version to make it more flexible and easy to make
these transitions?

One reason to use it would be local user simplicity. Rather than need to explicitly add new python3 releases to the default env list so that it does what we want every year or two we can just list py3,py2,linters in the default list and get most of the way there for local users. Then we can continue to be more specific in the CI jobs if that is desirable.
I do think we likely want to be explicit about the python versions we are using in CI testing. This makes it clear to developers who may need to reproduce or just understand why failures happen what platform is used. It also makes it explicit that "openstack runs on $pythonversion".
Clark

Including support for local users to refer to "py3" makes sense, as long
as we don't come to rely on it in CI. Users can also always be more
explicit if they need to be when running tests locally.

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-

[Andrey Pavlov]

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.

It would be useful to have more input from PTLs on this issue, so I'm
CCing all of them to get their attention.

Post by Doug Hellmann
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

Post by Doug Hellmann
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.
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
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

[Ben Nemec]

Resending from an address that is subscribed to the list. Apologies to
those of you who get this twice.

It would be useful to have more input from PTLs on this issue, so I'm
CCing all of them to get their attention.

Post by Doug Hellmann
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.
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
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/).

For everyone's awareness, we discussed this in the Oslo meeting today
and our first step is to see how many, if any, services are actually
relying on the oslo.service functionality that doesn't work in Python 3
today. From there we will come up with a plan for how to move forward.

https://bugs.launchpad.net/manila/+bug/1482633 is the original bug.

Post by Doug Hellmann
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).

And integration tests? I know for the initial python 3 goal we said
just unit and functional, but it seems to me that we can't claim full
python 3 compatibility until we can run our tempest jobs against python
3-based OpenStack.

Post by Doug Hellmann
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?

Alex can probably expand on this, but I know TripleO has some challenges
in this area. Specifically the fact that CentOS 7 will only ever
support Python 2 and CentOS 8 is planned to only support Python 3. Since
CentOS 8 is not a thing yet and no release dates are announced they're
having to use Fedora for Python 3 testing, which isn't something that
will be supported long-term. That makes things...complicated.

Some more details are in the PTG discussion wrap-up thread:
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128481.html

That said, I believe the plan is to be testing on Python 3 by T, so I
guess that's ultimately the answer to your question.

Post by Doug Hellmann
What else have I missed in these phases? Other jobs? Other blocking
conditions?
Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinf

[Matthew Treinish]

Post by Ben Nemec
Resending from an address that is subscribed to the list. Apologies to
those of you who get this twice.

It would be useful to have more input from PTLs on this issue, so I'm
CCing all of them to get their attention.

Post by Doug Hellmann
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.
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
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/).

For everyone's awareness, we discussed this in the Oslo meeting today and
our first step is to see how many, if any, services are actually relying on
the oslo.service functionality that doesn't work in Python 3 today. From
there we will come up with a plan for how to move forward.
https://bugs.launchpad.net/manila/+bug/1482633 is the original bug.

Post by Doug Hellmann
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).

And integration tests? I know for the initial python 3 goal we said just
unit and functional, but it seems to me that we can't claim full python 3
compatibility until we can run our tempest jobs against python 3-based
OpenStack.

They already are running, and have been since the Atlanta PTG (which was the
same cycle as the goal):

https://review.openstack.org/#/c/436540/

You can see the gate jobs history here:

http://status.openstack.org/openstack-health/#/job/tempest-full-py3

-Matt Treinish

Post by Ben Nemec

Post by Doug Hellmann
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?

Alex can probably expand on this, but I know TripleO has some challenges in
this area. Specifically the fact that CentOS 7 will only ever support
Python 2 and CentOS 8 is planned to only support Python 3. Since CentOS 8 is
not a thing yet and no release dates are announced they're having to use
Fedora for Python 3 testing, which isn't something that will be supported
long-term. That makes things...complicated.
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128481.html
That said, I believe the plan is to be testing on Python 3 by T, so I guess
that's ultimately the answer to your question.

Post by Doug Hellmann
What else have I missed in these phases? Other jobs? Other blocking
conditions?
Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Alex Schultz]

Post by Ben Nemec
Resending from an address that is subscribed to the list. Apologies to
those of you who get this twice.

It would be useful to have more input from PTLs on this issue, so I'm
CCing all of them to get their attention.

Post by Doug Hellmann
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.
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
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/).

For everyone's awareness, we discussed this in the Oslo meeting today and
our first step is to see how many, if any, services are actually relying on
the oslo.service functionality that doesn't work in Python 3 today. From
there we will come up with a plan for how to move forward.
https://bugs.launchpad.net/manila/+bug/1482633 is the original bug.

Post by Doug Hellmann
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).

And integration tests? I know for the initial python 3 goal we said just
unit and functional, but it seems to me that we can't claim full python 3
compatibility until we can run our tempest jobs against python 3-based
OpenStack.

Post by Doug Hellmann
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?

Alex can probably expand on this, but I know TripleO has some challenges in
this area. Specifically the fact that CentOS 7 will only ever support
Python 2 and CentOS 8 is planned to only support Python 3. Since CentOS 8 is
not a thing yet and no release dates are announced they're having to use
Fedora for Python 3 testing, which isn't something that will be supported
long-term. That makes things...complicated.
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128481.html
That said, I believe the plan is to be testing on Python 3 by T, so I guess
that's ultimately the answer to your question.

Yes from a TripleO perspective there are a few different ways to
address this, but we will likely need to follow the availability of
python3 on the current release of a given CentOS version. With the
switch to containers may allow us to decouple from the base OS python
a bit, but that would mean that we'd need to be able to pull in a
fedora images with python3 packages (via Kolla). The work on this
front is very early on so I'm not sure we have a timeline to commit to
T.

Thanks,
-Alex

Post by Ben Nemec

Post by Doug Hellmann
What else have I missed in these phases? Other jobs? Other blocking
conditions?
Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.opens

[Doug Hellmann]

Post by Alex Schultz

Post by Ben Nemec
Resending from an address that is subscribed to the list. Apologies to
those of you who get this twice.

It would be useful to have more input from PTLs on this issue, so I'm
CCing all of them to get their attention.

Post by Doug Hellmann
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.
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
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/).

For everyone's awareness, we discussed this in the Oslo meeting today and
our first step is to see how many, if any, services are actually relying on
the oslo.service functionality that doesn't work in Python 3 today. From
there we will come up with a plan for how to move forward.
https://bugs.launchpad.net/manila/+bug/1482633 is the original bug.

Post by Doug Hellmann
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).

And integration tests? I know for the initial python 3 goal we said just
unit and functional, but it seems to me that we can't claim full python 3
compatibility until we can run our tempest jobs against python 3-based
OpenStack.

Post by Doug Hellmann
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?

Alex can probably expand on this, but I know TripleO has some challenges in
this area. Specifically the fact that CentOS 7 will only ever support
Python 2 and CentOS 8 is planned to only support Python 3. Since CentOS 8 is
not a thing yet and no release dates are announced they're having to use
Fedora for Python 3 testing, which isn't something that will be supported
long-term. That makes things...complicated.
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128481.html
That said, I believe the plan is to be testing on Python 3 by T, so I guess
that's ultimately the answer to your question.

Yes from a TripleO perspective there are a few different ways to
address this, but we will likely need to follow the availability of
python3 on the current release of a given CentOS version. With the
switch to containers may allow us to decouple from the base OS python
a bit, but that would mean that we'd need to be able to pull in a
fedora images with python3 packages (via Kolla). The work on this
front is very early on so I'm not sure we have a timeline to commit to
T.
Thanks,
-Alex

OK, so it sounds like no earlier than T for TripleO.

What about some of the other deployment tools? Can members of those
teams give us any sort of guidance about when python 3 support is
expected?

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/lis

[Jean-Philippe Evrard]

We've been juggling with python3, ansible and multiple distros for a while now.
That dance hasn't been fruitful: many hidden issues, either due to
ansible modules, or our own modules, or upgrade issues.

I've recently decided to simplify the python2/3 story.

Queens and all the stable branches will be python2 only (python3 will
not be used anymore, to simplify the code)

For Rocky, we plan to use as much as possible the distribution
packages for the python stack, if it's recent enough for our source
installs.
Ubuntu 16.04 will have python2, SUSE has python2, CentOS has no
appropriate package, so we are pip installing things (and using
python2).
So... If people work on Ubuntu 18.04 support, we could try a python3
only system. Nobody worked on it right now.
Same for CentOS, because there is no usage of packages, we could use
Software Collections and have centos as a python3 only system. Sadly,
nobody has the cycles to do it now.

I am expecting we'll be using/seeing a lot more python3 in the future
with S, and wish for a python3 only "S" release.
But this solely depends on the work done in R to make sure 18.04 is
ready, as this would be our example, and "stepping stone" towards both
python2 and python3.

I am not sure this answers your question, as this is more gray than a
black or white answer.
But I am hoping we'll stabilize python3 this cycle, for ubuntu 18.04
at least, and other distros as a stretch goal.

Best regards,
Jean-Philippe Evrard (evrardjp)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.opensta

[Doug Hellmann]

Post by Jean-Philippe Evrard
We've been juggling with python3, ansible and multiple distros for a while now.
That dance hasn't been fruitful: many hidden issues, either due to
ansible modules, or our own modules, or upgrade issues.
I've recently decided to simplify the python2/3 story.
Queens and all the stable branches will be python2 only (python3 will
not be used anymore, to simplify the code)
For Rocky, we plan to use as much as possible the distribution
packages for the python stack, if it's recent enough for our source
installs.
Ubuntu 16.04 will have python2, SUSE has python2, CentOS has no
appropriate package, so we are pip installing things (and using
python2).
So... If people work on Ubuntu 18.04 support, we could try a python3
only system. Nobody worked on it right now.
Same for CentOS, because there is no usage of packages, we could use
Software Collections and have centos as a python3 only system. Sadly,
nobody has the cycles to do it now.
I am expecting we'll be using/seeing a lot more python3 in the future
with S, and wish for a python3 only "S" release.
But this solely depends on the work done in R to make sure 18.04 is
ready, as this would be our example, and "stepping stone" towards both
python2 and python3.
I am not sure this answers your question, as this is more gray than a
black or white answer.
But I am hoping we'll stabilize python3 this cycle, for ubuntu 18.04
at least, and other distros as a stretch goal.
Best regards,
Jean-Philippe Evrard (evrardjp)

I think your answer does help. It sounds like, unsurprisingly, you are
depending on work upstream in two different directions: You need the
OpenStack contributor community to ensure the code works on the platform
using Python 3, and then you need the OS vendors to provide appropriate
packages using Python 3.

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe
http://lists.

[Doug Hellmann]

Post by Ben Nemec
Resending from an address that is subscribed to the list. Apologies to
those of you who get this twice.

It would be useful to have more input from PTLs on this issue, so I'm
CCing all of them to get their attention.

Post by Doug Hellmann
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.
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
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/).

For everyone's awareness, we discussed this in the Oslo meeting today
and our first step is to see how many, if any, services are actually
relying on the oslo.service functionality that doesn't work in Python 3
today. From there we will come up with a plan for how to move forward.
https://bugs.launchpad.net/manila/+bug/1482633 is the original bug.

Post by Doug Hellmann
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).

And integration tests? I know for the initial python 3 goal we said
just unit and functional, but it seems to me that we can't claim full
python 3 compatibility until we can run our tempest jobs against python
3-based OpenStack.

Good point. The wiki page lists the integrated-gate-py35 job for
many projects, but not all will use that particular test job. I'm
not sure what other sort of integration jobs we do have, but I agree
we should have versions of them working for python 3.

Post by Ben Nemec

Post by Doug Hellmann
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?

Alex can probably expand on this, but I know TripleO has some challenges
in this area. Specifically the fact that CentOS 7 will only ever
support Python 2 and CentOS 8 is planned to only support Python 3. Since
CentOS 8 is not a thing yet and no release dates are announced they're
having to use Fedora for Python 3 testing, which isn't something that
will be supported long-term. That makes things...complicated.
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128481.html
That said, I believe the plan is to be testing on Python 3 by T, so I
guess that's ultimately the answer to your question.

Yes, that's more or less what I was looking for.

Doug

Post by Ben Nemec

Post by Doug Hellmann
What else have I missed in these phases? Other jobs? Other blocking
conditions?
Doug

[Victoria Martínez de la Cruz]

Although, I don't think glance uses oslo.service even in the case where
it's
using the standalone eventlet server. It looks like it launches
eventlet.wsgi
https://github.com/openstack/glance/blob/master/glance/common/wsgi.py
https://github.com/openstack/glance/blob/master/requirements.txt

It would probably independently suffer from https://bugs.launchpad.net/man
ila/+bug/1482633 in Python 3 then. IIUC the code started in oslo
incubator but projects like neutron and manila converted to use the
oslo.service version. There may be other copies of it still floating
around...
- ZB
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hi,

Jumping in now as I'm helping with py3 support efforts in the manila side.

In manila we have both support for Apache WSGI and the built-in server
(which depends in eventlet). Would it be a possible workaround to rely on
the Apache WSGI server while we wait for evenlet issues to be sorted out?
Is there any chance the upper constraints will be updated soon-ish and this
can be fixed in a newer eventlet version?

This is the only change it's preventing us to be fully py3 compatible,
hence it's a big deal for us.

Thanks,

Victoria