On Fri, Sep 14, 2018 at 4:22 PM, Jim Rollenhagen <j...@jimrollenhagen.com> wrote: > On Thu, Sep 13, 2018 at 9:46 PM, Mathieu Gagné <mga...@calavera.ca> wrote: >> >> On Thu, Sep 13, 2018 at 10:14 PM, Doug Hellmann <d...@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 <d...@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 >> >> >> <d...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev