Open Stack

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.

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