Open Stack

I discussed this a bit earlier with John and we came up with a thought that I was going to present after getting a little bit more documentation and spec around. With out going into too much detail, here is the basics of the idea.

Add a new column to all data models that allow us to inject with insert/update of rows the version of the Nova object it is for. Then we can add logic that prevents the contract from being run till a condition is met for a specific period of time after an object version has been deprecated. Once the depreciation window passes, it would be safe to remove the column form the model and contract the DB. This fits with our current thinking and the ability for conductor to down cast objects to older object versions and best of all, it is easy for us to maintain and access as the version for each row creation has access to the nova object and the version set in the object class.

If we set the criteria for breaking backwards compatibility and object downgrading with a new major version `VERSION = ‘2.0’` we know at that point it is safe to remove columns from the model that became deprecated prior to ‘2.0’ and allow the contract to run as long as all rows of data have a version in them of ‘2.0’. 

This does not have to be a major version and could really just be an arbitrary object version + N that we decide as a community.

-Ph

> On Jun 15, 2015, at 8:06 PM, Mike Bayer <mbayer at redhat.com> wrote:
> 
> 
> 
> On 6/15/15 6:37 PM, Mike Bayer wrote:
>> 
>> 
>> On 6/15/15 4:21 PM, Andrew Laski wrote:
>> 
>> If I had to visualize what an approach looks like that does this somewhat cleanly, other than just putting off contract until the API has naturally moved beyond it, it would involve a fixed and structured source of truth about the specific changes we care about, such as a versioning table or other data table indicating specific "remove()" directives we're checking for, and the application would be organized such that it can always get to this information from an in-memory-cached source before it makes decisions about queries. The information would need to support being pushed in from the outside such as via a message queue. This would still not protect against operations currently in progress failing but at least would prevent future operations from failing a first time.
>> 
> 
> Or, what I was thinking earlier before I focused too deeply on this whole thing, you basically get all running applications to no longer talk to the to-be-removed structures at all first, *then* do the contract.
> 
> That is, you're on version L.   You've done your expand, you're running the multi-schema version of the model.  All your data is migrated.    Now some config flag or something else changes somewhere (still need to work out this part), which says, "we're done with all the removed() columns".   All the apps ultimately get restarted with this new flag in place - the whole thing is now running without including removed() columns in the model (they're still there in the source code, but as I illustrated earlier, some conditional logic has prevented them from actually being part of the model on this new run).
> 
> *Then* you run the contract.     Then you don't have to worry about runtime failures or tracking specific columns or any of that. There's just some kind of state that indicates, "ready for L contract".   It's still something of a "version" but it is local to a single version of the software; instead of waiting for a full upgrade from version L to M, you have this internal state that can somehow move from L(m) to L(c).    That is a lot more doable and sane than trying to guess at startup / runtime what columns are being yanked.
> 
> 
> 
> 
> 
> 
> 
> 
> __________________________________________________________________________
> 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