Hi, Currently, ironic doesn't support ("live", "online", "rolling", or minimal-downtime) upgrades between named versions of ironic. (Where "named version" is the final release or stable release that is associated with a development cycle). So for example, Liberty -> Mitaka release.
We've been working towards that, and have a spec [1] and a design session [2] at the Austin Summit. Upon reading the spec, I started to wonder -- what do we mean/want, when we talk about supporting upgrades. Do we want to support: A. sequential named releases, eg. Mitaka -> Newton B. sequential major releases, eg 4.x -> 5.0; 5.0 -> 6.1 C. sequential minor releases, eg 5.1 -> 5.2 D. last named release to master E. last release (major or minor) to master F. some-SHA-more-recent-than-last-named to master. This could be some numbered (major or minor) release. Keep in mind that ironic may release any number of numbered releases between two named releases, so eg. 4.3.0, 5.0.0, 5.1.0 == Mitaka, 5.2.0, 6.0.0, 6.1.0, 7.0.0, 7.1.0, 7.2.0 == Newton. Note that there are two governance tags: supports-upgrade[3] and supports-rolling-upgrade[4], and I believe our goal is for supports-rolling-upgrade. I think and hope that we can all agree that A. is a must :) What constitutes a major release versus a minor release may have implications in this, but that should be in a separate discussion. What do people think? --ruby [1] https://review.openstack.org/299245 [2] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9267 [3] https://github.com/openstack/governance/blob/master/reference/tags/assert_supports-upgrade.rst [4] https://github.com/openstack/governance/blob/master/reference/tags/assert_supports-rolling-upgrade.rst
__________________________________________________________________________ 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