Open Stack

On 24 February 2015 at 22:53, Daniel P. Berrange <berrange at redhat.com> wrote:
> I was writing this mail for the past few days, but the nova thread
> today prompted me to finish it off & send it :-)

++

....
> The first two observations strongly suggest that the choice of 6
> months as a cycle length is a fairly arbitrary decision that can be
> changed without unreasonable pain. The third observation suggests a
> much shorter cycle length would smooth out the bumps and lead to a
> more efficient & satisfying development process for all involved.

I'm very glad to see this being discussed (again :)). Any proposal
that reduces our cycle time is going to get my enthusiastic support.

...
> Upgrades & deprecation
> ----------------------
>
> It is common right now for projects to say upgrades are only
> supported between releases N-1 and N. ie to go from Icehouse
> to Kilo, you need to first deploy Juno. This is passable when
> you're talking 6 month gaps between cycles, but when there are
> 2 month gaps it is not reasonable to expect everyone to be
> moving fast enough to keep up with every release. If an
> organization's beurocracy means they can't deploy more often
> than every 12 months, forcing them to deploy the 5 intermediate
> releases to run upgrade scripts is quite unpleasant. We would
> likely have to look at officially allowing upgrades between
> any (N-3, N-2, N-1) to N. From a database POV this should not
> be hard, since the DB migration scripts don't have any built
> in assumptions about this. Similarly the versioned objects used
> by Nova are quite flexible in this regard too, as long as the
> compat code isn't deleted too soon.
>
> Deprecation warnings would need similar consideration. It would
> not be sufficient to deprecate in one release and delete in the
> next. We'd likely want to say that depecations last for a given
> time period rather than number of releases, eg 6 months. This
> could be easily handled by simply including the date of initial
> deprecation in the deprecation message. It would thus be clear
> when the feature will be removed to all involved.

I think a useful thing here is to consider online upgrades vs offline
upgrades. If we care to we could say that online upgrades are only
supported release to release, with offline upgrades being supported by
releases up to 8 months apart. The benefit of this would be to reduce
our test matrix: online upgrades are subject to much greater
interactions between concurrent processes, and its hard enough to
validate that N -> N+1 works with any deep confidence vs also checking
that N->N+2, N->N+3 also work: for a 6 month sliding window to match
the current thing, we need to allow upgrades from Feb through August:
a Feb->Apr
b Feb->Jun
c Feb->Aug
d Apr-> Jun
e Apr->Aug
f Jun->Aug

We'd need to be testing all the combinations leading to the branch a
patch is for, so changes to Aug would need c, e and f all tested.


Thats 3 times the overhead of supporting:
Feb->Apr and then
Apr->Jun and then
Jun->Aug
serially where we'd only be testing one combination at a time.

-Rob


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