<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I definitely agree with everything said here.<div><br><div><div>On Jul 16, 2012, at 8:55 AM, David Kranz wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>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.<br><br>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<br>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.<br><br>Going forward, and this may be controversial, I think these kinds of issues would be best addressed by following these measures:<br><br>1. Require each blueprint that involves an API change or significant operational incompatibility to include a significant justification of<br> why it is necessary, what the impact would be, and a plan for deprecation/migration. This justification should assume that the remedy<br> will have to be applied to a large, running OpenStack system in its many possible variations, without having to shut down the system<br> for some unknown amount of time.<br><br>2. Require such blueprints to be approved by a technical committee that includes a significant representation of users/operators. The tradeoffs can<br>be difficult and need to be discussed.<br><br>3. The technical committee should declare that the bar for incompatible changes is high, and getting higher.<br><br>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<br>community (and others) would more than compensate for that.<br><br> -David<br><br><br><br>On 7/16/2012 8:04 AM, Sean Dague wrote:<br><blockquote type="cite">On 07/12/2012 05:40 PM, Vishvananda Ishaya wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Excellent points. Let me make the following proposal:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">1) Leave the code in nova-volume for now.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">2) Document and test a clear migration path to cinder.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">3) Take the working example upgrade to the operators list and ask them for opinions.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">4) Decide based on their feedback whether it is acceptable to cut the nova-volume code out for folsom.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">+1<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> -Sean<br></blockquote><blockquote type="cite"><br></blockquote><br><br>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--<br>George Reese - Chief Technology Officer, enStratus<br>e: <a href="mailto:george.reese@enstratus.com">george.reese@enstratus.com</a> Skype: nspollution t: @GeorgeReese p: +1.207.956.0217<br>enStratus: Enterprise Cloud Management - @enStratus - <a href="http://www.enstratus.com/">http://www.enstratus.com</a><br>To schedule a meeting with me: <a href="http://tungle.me/GeorgeReese">http://tungle.me/GeorgeReese</a></div></div></span></span>
</div>
<br></div></body></html>