On 01/30/2015 07:23 AM, Sandy Walsh wrote:
________________________________________
From: Johannes Erdfelt [[email protected]]
Sent: Thursday, January 29, 2015 9:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][tc] SQL Schema Downgrades and Related Issues
On Thu, Jan 29, 2015, Morgan Fainberg <[email protected]> wrote:
The concept that there is a utility that can (and in many cases
willfully) cause permanent, and in some cases irrevocable, data loss
from a simple command line interface sounds crazy when I try and
explain it to someone.
The more I work with the data stored in SQL, and the more I think we
should really recommend the tried-and-true best practices when trying
to revert from a migration: Restore your DB to a known good state.
You mean like restoring from backup?
Unless your code deploy fails before it has any chance of running, then
you could have had new instances started or instances changed and then
restoring from backups would lose data.
If you meant another way of restoring your data, then there are
some strategies that downgrades could employ that doesn't lose data,
but there is nothing that can handle 100% of cases.
All of that said, for the Rackspace Public Cloud, we have never rolled
back our deploy. We have always rolled forward for any fixes we needed.
>From my perspective, I'd be fine with doing away with downgrades, but
I'm not sure how to document that deployers should roll forward if they
have any deploy problems.
JE
Yep ... downgrades simply aren't practical with a SQL-schema based
solution. Too coarse-grained.
We'd have to move to a schema-less model, per-record versioning and
up-down conversion at the Nova Objects layer. Or, possibly introduce
more nodes that can deal with older versions. Either way, that's a big
hairy change
Horse pocky! Schema less means "implied contract instead of implicit."
That would be madness. Please take the NoSQL good, SQL bad approach of
of the conversation, as absotutely (yes, absotutely) everything we have
here is doubly true for NoSQL, we just don't hammer on it as much. We
don't even document the record formats in the NoSQL cases in Keystone so
we can break them both willy and nilly, but have often found that we are
just stuck. Usually, we are only dealing with the token table, and so
we just dump the old tokens and shake our heads sadly.
.
The upgrade code is still required, so removing the downgrades (and
tests, if any) is a relatively small change to the code base.
The bigger issue is the anxiety the deployer will experience until a
patch lands.
-S
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
