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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
