________________________________________ From: Robert Collins [robe...@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. __________________________________________________________________________ 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
