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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.com 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
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
