<div>Hello,</div><div><br></div>I'm not an OpenStack developer nor any type of developer. I am, however, heavily involved with operations for a few production OpenStack environments. I understand the debate going on and wanted to add an administrator's point of view.<div>
<br></div><div>For admins, OpenStack is not our job, but a tool we use in our job. It's terribly frustrating when that tool drastically changes every six months. </div><div><br></div><div>I find Gabriel's reply interesting and sane. I think if it was agreed upon to ensure N+1 compatibility, then OpenStack should adhere to that. </div>
<div><br></div><div>The change being discussed involves storage volumes. This is dead serious. If the migration goes awry, there's potential for production data loss. If the badly-migrated OpenStack environment is used to offer services for outside customers, we've just lost data for those customers. It's one of the worst scenarios for admins.</div>
<div><br></div><div>If upgrading from one version of OpenStack to the next is too dangerous due to the possibility of getting into situations such as described above, then it needs to be clearly announced. There's a reason why major RHEL releases are maintained in parallel for so long.</div>
<div><br></div><div>With regard to Option 1, I understand the benefits of making this change. If Option 1 was chosen, IMO, the best-case scenario would be if the extra work involved with upgrading to Cinder/Folsom was just a schema migration and everything else still worked as it did with Essex. </div>
<div><br></div><div>If this were to happen, though, I would spend /weeks/ testing and planning the Folsom upgrade. I'd estimate that my production environments would make it to Folsom 3 months after it was released. But then what major change am I going to have to worry about in another 3 months?</div>
<div><br></div><div>Thanks,</div><div>Joe</div><div><br><br><div class="gmail_quote">On Thu, Jul 12, 2012 at 2:48 PM, Gabriel Hurley <span dir="ltr"><<a href="mailto:Gabriel.Hurley@nebula.com" target="_blank">Gabriel.Hurley@nebula.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The stated and agreed-upon goal from Essex forward is to make the core OpenStack projects N+1 compatible (e.g. Essex->Folsom, Folsom->Grizzly), and to make
the clients capable of talking to every API version forever.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Anything standing in the way of that should be considered a release-blocking bug, and should be filed against the appropriate projects. I for one intend to
see to that as best I can.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">That said, there *<b>is</b>* a grey area around “migration” steps like Nova Volume -> Cinder. If the migration path is clear, stable, well-documented, uses
the same schemas and same APIs… I’d say that *<b>may</b>* still fall into the category of N+1 compatible. It sounds like that’s the idea here, but that we need to thoroughly vet the practicality of that assertion. I don’t think we can decide this without proof
that the clean transition is 100% possible.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Code isn’t the only thing of value; constructively and respectfully shaping design decisions is great, testing and filing bugs is also fantastic. Profanity
and disrespect are not acceptable. Ever.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">All the best,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p style="margin-left:27.0pt">
<u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>-<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Gabriel<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> </span></p></div></div></blockquote></div><div><br></div>-- <br>Joe Topjian<div>Systems Administrator</div>
<div>Cybera Inc.</div><div><br></div><div><a href="http://www.cybera.ca" target="_blank">www.cybera.ca</a></div><div><br></div><div><font color="#666666"><span>Cybera</span><span> is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.</span></font></div>
<br>
</div>