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 <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ 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
