[openstack-dev] Online Migrations.
mbayer at redhat.com
Tue Jun 16 00:06:32 UTC 2015
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.
More information about the OpenStack-dev