<div dir="ltr">Hi Doug,<div><br></div><div>There is no ec2-api project on the link.</div><div>But we have voted job
<a href="http://logs.openstack.org/85/552085/2/check/openstack-tox-py35/6464ed8/" rel="nofollow" style="text-decoration:underline;color:rgb(6,84,172);font-family:sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">openstack-tox-py35</a>
</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Regards,<div>Andrey Pavlov.</div></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Apr 30, 2018 at 6:06 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It would be useful to have more input from PTLs on this issue, so I'm<br>
CCing all of them to get their attention.<br>
<br>
Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400:<br>
> It's time to talk about the next steps in our migration from python<br>
> 2 to python 3.<br>
> <br>
> Up to this point we have mostly focused on reaching a state where<br>
> we support both versions of the language. We are not quite there<br>
> with all projects, as you can see by reviewing the test coverage<br>
> status information at<br>
> <a href="https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects" rel="noreferrer" target="_blank">https://wiki.openstack.org/<wbr>wiki/Python3#Python_3_Status_<wbr>of_OpenStack_projects</a><br>
> <br>
> Still, we need to press on to the next phase of the migration, which<br>
> I have been calling "Python 3 first". This is where we use python<br>
> 3 as the default, for everything, and set up the exceptions we need<br>
> for anything that still requires python 2.<br>
> <br>
> To reach that stage, we need to:<br>
> <br>
> 1. Change the documentation and release notes jobs to use python 3.<br>
> (The Oslo team recently completed this, and found that we did<br>
> need to make a few small code changes to get them to work.)<br>
> 2. Change (or duplicate) all functional test jobs to run under<br>
> python 3.<br>
> 3. Change the packaging jobs to use python 3.<br>
> 4. Update devstack to use 3 by default and require setting a flag to<br>
> use 2. (This may trigger other job changes.)<br>
> <br>
> At that point, all of our deliverables will be produced using python<br>
> 3, and we can be relatively confident that if we no longer had<br>
> access to python 2 we could still continue operating. We could also<br>
> start updating deployment tools to use either python 3 or 2, so<br>
> that users could actually deploy using the python 3 versions of<br>
> services.<br>
> <br>
> Somewhere in that time frame our third-party CI systems will need<br>
> to ensure they have python 3 support as well.<br>
> <br>
> After the "Python 3 first" phase is completed we should release<br>
> one series using the packages built with python 3. Perhaps Stein?<br>
> Or is that too ambitious?<br>
> <br>
> Next, we will be ready to address the prerequisites for "Python 3<br>
> only," which will allow us to drop Python 2 support.<br>
> <br>
> We need to wait to drop python 2 support as a community, rather<br>
> than going one project at a time, to avoid doubling the work of<br>
> downstream consumers such as distros and independent deployers. We<br>
> don't want them to have to package all (or even a large number) of<br>
> the dependencies of OpenStack twice because they have to install<br>
> some services running under python 2 and others under 3. Ideally<br>
> they would be able to upgrade all of the services on a node together<br>
> as part of their transition to the new version, without ending up<br>
> with a python 2 version of a dependency along side a python 3 version<br>
> of the same package.<br>
> <br>
> The remaining items could be fixed earlier, but this is the point<br>
> at which they would block us:<br>
> <br>
> 1. Fix oslo.service functional tests -- the Oslo team needs help<br>
> maintaining this library. Alternatively, we could move all<br>
> services to use cotyledon (<a href="https://pypi.org/project/cotyledon/" rel="noreferrer" target="_blank">https://pypi.org/project/<wbr>cotyledon/</a>).<br>
> <br>
> 2. Finish the unit test and functional test ports so that all of<br>
> our tests can run under python 3 (this implies that the services<br>
> all run under python 3, so there is no more porting to do).<br>
> <br>
> Finally, after we have *all* tests running on python 3, we can<br>
> safely drop python 2.<br>
> <br>
> We have previously discussed the end of the T cycle as the point<br>
> at which we would have all of those tests running, and if that holds<br>
> true we could reasonably drop python 2 during the beginning of the<br>
> U cycle, in late 2019 and before the 2020 cut-off point when upstream<br>
> python 2 support will be dropped.<br>
> <br>
> I need some info from the deployment tool teams to understand whether<br>
> they would be ready to take the plunge during T or U and start<br>
> deploying only the python 3 version. Are there other upgrade issues<br>
> that need to be addressed to support moving from 2 to 3? Something<br>
> that might be part of the platform(s), rather than OpenStack itself?<br>
> <br>
> What else have I missed in these phases? Other jobs? Other blocking<br>
> conditions?<br>
> <br>
> Doug<br>
</blockquote></div><br></div>