This message is a summary of the discussion about enabling integration testing 
under Python 3 from the summit. The full notes are in 
https://etherpad.openstack.org/p/liberty-cross-project-python3 and the spec is 
up at https://review.openstack.org/#/c/177375/

tl;dr: Most of our libraries now support Python 3, and run their unit tests 
there. We have several application-level projects ready to start porting their 
code to Python 3 as well. Running unit tests for the application code under 
Python 3 will be an important step, but won’t be sufficient to claim Python 3 
support. The proposed changes to devstack allow each application project to add 
a test job to run their code under Python 3 when they think they are ready, 
allowing applications to port one at a time.


We agreed that we need to keep supporting Python 2.7 and 3.x simultaneously for 
some time, until we are at a point where we can reliably tell deployers to 
shift most/all of their stack. We are explicitly putting off discussion of more 
detailed criteria for that until we actually have *any* project that runs fully 
on Python 3.

We agreed that we would only support one version of python 3 at a time. Some 
distros may choose to package 3.5 when it is available (soon), but we agreed 
that we would continue working with python 3.4 because it is more widely 
supported on our platforms (directly, or through supported extra repositories). 
Ubuntu has an issue with their 3.4 package due to missing a backport that 
causes segfaults under some circumstances. The packagers are aware of the 
issue, and zul is going to work with them to raise the priority of updating the 
package. If the update isn’t released in a reasonable amount of time, we can 
fall back to testing on Debian Jessie instead, but that will take some work 
from the infra team.

We agreed to use environment markers in our packaging metadata to control 
version-specific requirements, and remove the use of version-specific 
requirements*.txt files. The current release of pbr understands environment 
markers in setup.cfg, but we still need to update projects with 
version-specific requirements to list their dependencies there instead of 
requirements.txt and to fix up the global-requirements tools to update 
setup.cfg instead of the requirements files. I think lifeless has signed up for 
some of that work, but maybe not all of it?

We agreed to move to PyMySQL as our database driver, since the one we are using 
now appears to be unmaintained and does not support Python 3. sdague has a 
series of patches up for devstack to make this change, starting with 
https://review.openstack.org/#/c/184489 and we will need to update the 
dependencies of oslo.db as well.

We still need to approve the spec (https://review.openstack.org/#/c/177375/) 
and I need to set up the job template so that projects can turn the job on when 
they are ready to try it out.

Please let me know if you think I missed any details, or misunderstood 
something as agreed to. Or, of course, if you weren’t there and see something 
wrong with the plan after looking at it now.

Doug


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

Reply via email to