Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120712/dff98651/attachment.html>