Open Stack

On 01/30/2015 07:23 AM, Sandy Walsh wrote:
>> ________________________________________
>> From: Johannes Erdfelt [johannes at erdfelt.com]
>> 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 <morgan.fainberg at gmail.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev