[openstack-dev] backwards compatibility followup

Perry, Sean sean.perry at hpe.com
Tue Apr 26 23:32:16 UTC 2016

From: Robert Collins [robertc at robertcollins.net]
Sent: Tuesday, April 26, 2016 4:07 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] backwards compatibility followup

Here is the choice I think we're still struggling with:
 - should we support in-place upgrades? If we do, we need at least 1,
possibly more, versions of compatibility such that e.g. mitaka Nova
can run with newton olso+clientlibs
 - or should we explicitly state that we don't support in-place
upgrades - that deployment methods must be architected to avoid ever
encountering the situation where a client or one of N services is
going to be upgraded on a single python environment: all clients and
services must be upgraded together, or none.

What if we update the docs and tell people to put any services on a shared system into independent virtualenvs?

If a box only runs neutron or whatever all is well. The issue happens when you mix and match services on a single host. Which is exactly what virtualenv was intended to fix.

More information about the OpenStack-dev mailing list