nova team mailing list archive

[Blake Yeager <blake.yeager@xxxxxxxxxxxxx>]

On 10/13/10 4:04 PM, "Soren Hansen" <soren@xxxxxxxxxxxxx> wrote:

> On 13-10-2010 15:34, Rick Clark wrote:
>>> In my dictionary, "dot releases" are "micro releases" that come
>>> out in between "real releases". We have Austin coming out in a
>>> couple of weeks, and Bexar is supposed to follow 3 months after
>>> that. A "dot release" of Austin would be another release based on
>>> Austin that adds some important bug fixes or similar that we find
>>> as we move along (typically backported from later releases).
>>> 
>>> As an example of a project that does this, Ubuntu designates every
>>>  fourth release a "Long Term Support" release. These releases get a
>>>  number of dot releases in their lifetime (i.e. support timeframe).
>>>  "Regular" Ubuntu releases don't get dot releases.
>>> 
>>> I don't think we'll want to follow that particular pattern.
>> I would rather follow the pattern of KVM, that did not support or
>> backport patches until far down the line.
> 
> I agree completely. In fact, I totally stole the model outlined below
> from KVM :)
> 

Agreed, there is going to be way too much changing in the first few releases
for us to be supporting dot releases.  As mentioned below, at some point
once the project has matured a bit, I think there is a lot value in having
longer term releases.  Enterprises or service providers may want to continue
running a specific release and have the ability to update for bug fixes,
etc, without including all of the new functionality which they may not be in
a position to support or test.

>>> Instead, I propose we stick to our three months' (or whatever
>>> we'll end up with) cadence. With such frequent releases, the burden
>>> of maintaining older releases significantly past their release
>>> date doesn't seem worth while for us as a project. However, if
>>> someone wants to maintain a stable branch of e.g. Austin, we let
>>> them do so within the project. The support and maintenance burden
>>> is primarily on them, but we provide the framework for them to do
>>> so. We need to work out in detail how this will work, of course,
>>> since their work will reflect upon the project as a whole.
>> The basic reason for not supporting and backporting patches is that
>> the rate of change in the code is still high.
> 
> Again, agree completely. I had a paragraph to roughly the same effect in
> my first draft of my e-mail :)
> 
>> Fixing bugs in old branches might be completely different work.  We
>> need to focus on moving the project forward, right now.
> 
> *nod* That's exactly why I don't think /we/ should be doing it.
> 
>> When we reach a point that the rate of change in the code has slowed
>> and we are more feature complete we will come up with a full plan to
>> support multiple releases.  Until then, we fix all bugs in trunk.
> 
> Right. I'm simply trying to acommodate the potential reality of a linux
> distro coming along and wanting to ship a particular version of
> Openstack and want to support it for a long time. I don't expect that to
> happen in the (very) near future. Frankly, I think that would be silly.
> Come Ubuntu's next LTS (expected in April 2012), it'll be an entirely
> different story. Also way sooner than that.

Although I agree with the position we are taking, I think it is important to
mention an implicit commitment that we are making when we take this stance.
If we aren't going to support dot releases right out of the gate then we
need to commit to building the tools which would be required to enable early
adopters to upgrade to newer versions easily.  We shouldn't penalize the
groups that build implementations of OpenStack in the short term.  If
someone is going to do a major re-factor or completely change the way
something works in such a way that it makes an in-place upgrade difficult
they should also be required to build tools required to make an upgrade
work.

I would hate for someone to build a cloud based on OpenStack Compute, get a
bunch of VMs running in it and then us telling them that if they want to
move to the latest version they have to start over or go through some
extremely unpleasant upgrade process. This is especially important when it
comes to upgrades of the node agent since those same boxes are running VMs
you can't just re-kick the box and start over.

   



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.