Open Stack

Thanks everyone for coming to the backwards compat for clients and
libraries session.

Here are the things I think we agreed on:
 - clients need to talk to all versions of openstack clouds
 - oslo libraries already do need to do backwards compat - josh,
myself, dims, doug are all striving for that in reviews
 - some fraction of our deploys - somewhere between 1% and 50% - are
trying to do in-place upgrades where e.g. nova is upgraded and then
later neutron, which runs into neutron having to work with the new
libraries the nova upgrade dragged in.

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.

If we decide to support in-place upgrades, we can figure out how to
test that effectively; its a linear growth with the number of stable
releases we choose to support.

If we decide not to support them, we have no further requirement to
have any cross-over compat between OpenStack releases - while we will
still have to be backwards compatible on individual changes (so that
we can get them rolled out and used), we can do our garbage collection
much more rapidly - even same-cycle.


https://etherpad.openstack.org/p/newton-backwards-compat-libs

-Rob

-- 
Robert Collins <rbtcollins at hpe.com>
Distinguished Technologist
HP Converged Cloud