Open Stack

On Fri, Sep 14, 2018 at 4:22 PM, Jim Rollenhagen <jim at jimrollenhagen.com> wrote:
> On Thu, Sep 13, 2018 at 9:46 PM, Mathieu Gagné <mgagne at calavera.ca> wrote:
>>
>> On Thu, Sep 13, 2018 at 10:14 PM, Doug Hellmann <doug at doughellmann.com>
>> wrote:
>> > Excerpts from Mathieu Gagné's message of 2018-09-13 20:09:12 -0400:
>> >> On Thu, Sep 13, 2018 at 7:41 PM, Doug Hellmann <doug at doughellmann.com>
>> >> wrote:
>> >> > Excerpts from Mathieu Gagné's message of 2018-09-13 14:12:56 -0400:
>> >> >> On Wed, Sep 12, 2018 at 2:04 PM, Doug Hellmann
>> >> >> <doug at doughellmann.com> wrote:
>> >> >> >
>> >> >> > IIRC, we also talked about not supporting multiple versions of
>> >> >> > python on a given node, so all of the services on a node would
>> >> >> > need
>> >> >> > to be upgraded together.
>> >> >> >
>> >> >>
>> >> >> Will services support both versions at some point for the same
>> >> >> OpenStack release? Or is it already the case?
>> >> >>
>> >> >> I would like to avoid having to upgrade Nova, Neutron and Ceilometer
>> >> >> at the same time since all end up running on a compute node and
>> >> >> sharing the same python version.
>> >> >
>> >> > We need to differentiate between what the upstream community supports
>> >> > and what distros support. In the meeting in Vancouver, we said that
>> >> > the community would support upgrading all of the services on a
>> >> > single node together. Distros may choose to support more complex
>> >> > configurations if they choose, and I'm sure patches related to any
>> >> > bugs would be welcome.
>> >>
>> >> We maintain and build our own packages with virtualenv. We aren't
>> >> bound to distribution packages.
>> >
>> > OK, I should rephrase then. I'm talking about the limits on the
>> > tests that I think are useful and reasonable to run upstream and
>> > for the community to support.
>> >
>> >> > But I don't think we can ask the community
>> >> > to support the infinite number of variations that would occur if
>> >> > we said we would test upgrading some services independently of
>> >> > others (unless I'm mistaken, we don't even do that for services
>> >> > all using the same version of python 2, today).
>> >>
>> >> This contradicts what I heard in fishbowl sessions from core reviewers
>> >> and read on IRC.
>> >> People were under the false impression that you need to upgrade
>> >> OpenStack in lock steps when in fact, it has never been the case.
>> >> You should be able to upgrade services individually.
>> >>
>> >> Has it changed since?
>> >
>> > I know that some deployments do upgrade components separately, and
>> > it works in some configurations.  All we talked about in Vancouver
>> > was how we would test upgrading python 2 to python 3, and given
>> > that the community has never, as far as I know, run upgrade tests
>> > in CI that staggered the upgrades of components on a given node,
>> > there seemed no reason to add those tests just for the python 2 to
>> > 3 case.
>> >
>> > Perhaps someone on the QA team can correct me if I'm wrong about the
>> > history there.
>> >
>>
>> Or maybe it's me that misinterpreted the actual impact of not
>> supported 2 versions of Python at the same time.
>>
>> Lets walk through an actual upgrade scenario.
>>
>> I suppose the migration to Python 3 will happen around Stein and
>> therefore affects people upgrading from Rocky to Stein. At this point,
>> an operator should already be running Ubuntu Bionic which supports
>> both Python 2.7 and 3.6.
>>
>> If that operator is using virtualenv (and not distribution packages),
>> it's only a matter a building new virtualenv using Python 3.6 for
>> Stein instead. This means installing both Python 2.7/3.6 on the same
>> node should be enough to upgrade and switch to Python 3.6 on a per
>> project/service basis.
>>
>> My main use case is with the compute node which has multiple services
>> running. Come to think of it, it's a lot less impactful than I
>> thought.
>>
>> Let me know if I got some details wrong. But if the steps are similar
>> to what I described above, I no longer have concerns or objections.
>
>
>
> 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
> https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation-timeline.html#python2-deprecation-timeline,
> notably:
>
> 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.
> 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).
>
> This gives operators an opportunity to keep the Python 2->3 upgrade
> completely separate from an OpenStack upgrade.
>
> So in short, yes, you'll be fine :)
>
> // jim


Thanks for the clarification. Much appreciated!

>
>>
>>
>> I think the only people who could be concerned is those doing rolling
>> upgrading, which could impact RPC message encoding as described by
>> Thomas. But you are already addressing it so I will just read and see
>> where this is going.
>>
>> Thanks
>>
>> --
>> Mathieu
>>

--
Mathieu