openstack team mailing list archive

[George Reese <george.reese@xxxxxxxxxxxxx>]

I definitely agree with everything said here.

On Jul 16, 2012, at 8:55 AM, David Kranz wrote:

> An excellent idea. I believe that if the below message had been sent in April, the tenor of the discussion would have been much different. I think a main source of angst around this was that there was no mention at the Folsom summit of nova-volume being simply removed immediately, except perhaps inside the session devoted to this subject which many could not attend.
> 
> Stepping up a level, it is hard for a project to move from a developer-centric (no real customers) way of doing things to one driven by
> having real enterprise users/customers. I know this from past experience. At a certain point, we will have to live with APIs or code organizations that are sub-optimal because it is just too much of a burden on real users/operators to change them. Obviously some members of the community believe this tipping point was the Essex release. It is also inevitable that development will "slow down" by some measures as the cost of regressions rises and what George Reese called "technical debt" has to be repaid.
> 
> Going forward, and this may be controversial, I think these kinds of issues would be best addressed by following these measures:
> 
> 1. Require each blueprint that involves an API change or significant operational incompatibility to include a significant justification of
>    why it is necessary, what the impact would be, and a plan for deprecation/migration. This justification should assume that the remedy
>    will have to be applied to a large, running OpenStack system in its many possible variations, without having to shut down the system
>   for some unknown amount of time.
> 
> 2. Require such blueprints to be approved by a technical committee that includes a significant representation of users/operators. The tradeoffs can
> be difficult and need to be discussed.
> 
> 3. The technical committee should declare that the bar for incompatible changes is high, and getting higher.
> 
> Some might argue that this is too much of a burden and takes authority away from PTLs, but I think the statement of stability to the
> community (and others) would more than compensate for that.
> 
> -David
> 
> 
> 
> On 7/16/2012 8:04 AM, Sean Dague wrote:
>> On 07/12/2012 05:40 PM, Vishvananda Ishaya wrote:
>>> Excellent points. Let me make the following proposal:
>>> 
>>> 1) Leave the code in nova-volume for now.
>>> 2) Document and test a clear migration path to cinder.
>>> 3) Take the working example upgrade to the operators list and ask them for opinions.
>>> 4) Decide based on their feedback whether it is acceptable to cut the nova-volume code out for folsom.
>> 
>> +1
>> 
>>    -Sean
>> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

--
George Reese - Chief Technology Officer, enStratus
e: george.reese@xxxxxxxxxxxxx    Skype: nspollution    t: @GeorgeReese    p: +1.207.956.0217
enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com
To schedule a meeting with me: http://tungle.me/GeorgeReese