Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160419/e699560b/attachment.html>