[openstack-dev] [goals][python3] mixed versions?
jim at jimrollenhagen.com
Fri Sep 14 20:22:58 UTC 2018
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>
> > 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>
> >> > 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
> 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
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 :)
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev