This is exactly the sort of interaction we need between the two perspectives of the OpenStack community.
Thanks Chris Sent from my iPad On Jul 12, 2012, at 11:20 PM, "Joe Topjian" <joe.topj...@cybera.ca> wrote: > Hello, > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. > > 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? > > Thanks, > Joe > > > On Thu, Jul 12, 2012 at 2:48 PM, Gabriel Hurley <gabriel.hur...@nebula.com> > wrote: > 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. > > > > 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. > > > > That said, there *is* 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 *may* 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. > > > > 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. > > > > All the best, > > > > - Gabriel > > > > > -- > Joe Topjian > Systems Administrator > Cybera Inc. > > www.cybera.ca > > Cybera is a not-for-profit organization that works to spur and support > innovation, for the economic benefit of Alberta, through the use of > cyberinfrastructure. > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
