Open Stack

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.topjian at 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.Hurley at 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120713/2db5d6d6/attachment.html>