<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 13, 2018 at 9:46 PM, Mathieu Gagné <span dir="ltr"><<a href="mailto:mgagne@calavera.ca" target="_blank">mgagne@calavera.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Sep 13, 2018 at 10:14 PM, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>
> Excerpts from Mathieu Gagné's message of 2018-09-13 20:09:12 -0400:<br>
>> On Thu, Sep 13, 2018 at 7:41 PM, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>
>> > Excerpts from Mathieu Gagné's message of 2018-09-13 14:12:56 -0400:<br>
>> >> On Wed, Sep 12, 2018 at 2:04 PM, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br>
>> >> ><br>
>> >> > IIRC, we also talked about not supporting multiple versions of<br>
>> >> > python on a given node, so all of the services on a node would need<br>
>> >> > to be upgraded together.<br>
>> >> ><br>
>> >><br>
>> >> Will services support both versions at some point for the same<br>
>> >> OpenStack release? Or is it already the case?<br>
>> >><br>
>> >> I would like to avoid having to upgrade Nova, Neutron and Ceilometer<br>
>> >> at the same time since all end up running on a compute node and<br>
>> >> sharing the same python version.<br>
>> ><br>
>> > We need to differentiate between what the upstream community supports<br>
>> > and what distros support. In the meeting in Vancouver, we said that<br>
>> > the community would support upgrading all of the services on a<br>
>> > single node together. Distros may choose to support more complex<br>
>> > configurations if they choose, and I'm sure patches related to any<br>
>> > bugs would be welcome.<br>
>><br>
>> We maintain and build our own packages with virtualenv. We aren't<br>
>> bound to distribution packages.<br>
><br>
> OK, I should rephrase then. I'm talking about the limits on the<br>
> tests that I think are useful and reasonable to run upstream and<br>
> for the community to support.<br>
><br>
>> > But I don't think we can ask the community<br>
>> > to support the infinite number of variations that would occur if<br>
>> > we said we would test upgrading some services independently of<br>
>> > others (unless I'm mistaken, we don't even do that for services<br>
>> > all using the same version of python 2, today).<br>
>><br>
>> This contradicts what I heard in fishbowl sessions from core reviewers<br>
>> and read on IRC.<br>
>> People were under the false impression that you need to upgrade<br>
>> OpenStack in lock steps when in fact, it has never been the case.<br>
>> You should be able to upgrade services individually.<br>
>><br>
>> Has it changed since?<br>
><br>
> I know that some deployments do upgrade components separately, and<br>
> it works in some configurations.  All we talked about in Vancouver<br>
> was how we would test upgrading python 2 to python 3, and given<br>
> that the community has never, as far as I know, run upgrade tests<br>
> in CI that staggered the upgrades of components on a given node,<br>
> there seemed no reason to add those tests just for the python 2 to<br>
> 3 case.<br>
><br>
> Perhaps someone on the QA team can correct me if I'm wrong about the<br>
> history there.<br>
><br>
<br>
</div></div>Or maybe it's me that misinterpreted the actual impact of not<br>
supported 2 versions of Python at the same time.<br>
<br>
Lets walk through an actual upgrade scenario.<br>
<br>
I suppose the migration to Python 3 will happen around Stein and<br>
therefore affects people upgrading from Rocky to Stein. At this point,<br>
an operator should already be running Ubuntu Bionic which supports<br>
both Python 2.7 and 3.6.<br>
<br>
If that operator is using virtualenv (and not distribution packages),<br>
it's only a matter a building new virtualenv using Python 3.6 for<br>
Stein instead. This means installing both Python 2.7/3.6 on the same<br>
node should be enough to upgrade and switch to Python 3.6 on a per<br>
project/service basis.<br>
<br>
My main use case is with the compute node which has multiple services<br>
running. Come to think of it, it's a lot less impactful than I<br>
thought.<br>
<br>
Let me know if I got some details wrong. But if the steps are similar<br>
to what I described above, I no longer have concerns or objections.<br></blockquote><div><br></div><div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br class="gmail-Apple-interchange-newline">The plan is to maintain support for both Python 2 and 3 in the T release (and possibly S, if the projects get py3 work done quickly). See <a href="https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation-timeline.html#python2-deprecation-timeline">https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation-timeline.html#python2-deprecation-timeline</a>, notably:</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">2. All projects must complete the work for Python 3 support by the end of the T cycle, unless they are blocked for technical reasons by dependencies they rely on.</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">4. Existing projects under TC governance at the time this resolution is accepted must not drop support for Python 2 before the beginning of the U development cycle (currently anticipated for late 2019).</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">This gives operators an opportunity to keep the Python 2->3 upgrade completely separate from an OpenStack upgrade. </div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">So in short, yes, you'll be fine :)</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">// jim</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think the only people who could be concerned is those doing rolling<br>
upgrading, which could impact RPC message encoding as described by<br>
Thomas. But you are already addressing it so I will just read and see<br>
where this is going.<br>
<br>
Thanks<br>
<br>
--<br>
Mathieu<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>