Excerpts from Alex Schultz's message of 2018-04-30 15:43:16 -0600: > On Mon, Apr 30, 2018 at 3:16 PM, Ben Nemec <openst...@nemebean.com> wrote: > > Resending from an address that is subscribed to the list. Apologies to > > those of you who get this twice. > > > > On 04/30/2018 10:06 AM, Doug Hellmann 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/). > > > > > > 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. > > > >>> > >>> 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. > > > >>> > >>> 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. > > > > 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev