[openstack-dev] Online Migrations.
mbayer at redhat.com
Mon Jun 15 15:54:23 UTC 2015
On 6/15/15 9:21 AM, Philip Schwartz wrote:
> This weekend, I discussed the requested change at length with Mike. I
> think before moving forward, we need a better understanding of what is
> trying to be achieved.
> Request: Add the ability to verify migrations are completed prior to
> As discussed here previously, I worked out a setup using the .info
> dict of the Column’s that are to be removed or Migrated. But came
> across and issue that is more concerning.
> In order to contract the DB, the columns need to be removed from the
> Model Classes. We can do this just prior to scanning the Model Classes
> to determine schema migrations, but the columns would still exist in
> the Model Class for all other loading of the model, i.e. at ORM
> query’s and such.
> After discussing this with Mike, there looks to be 3 options:
> 1. Remove the columns at contract time and also build a mechanism to
> scan for the same .info entry at Query time to prevent it from
> being used.
> 2. Remove the columns at contract time and create a mechanism that on
> load of data models once the migration is complete would remove
> the columns (forced restart of service once migration is done will
> allow the ORM queries to no longer see the column)
> 3. Build the controls into our process with a way of storing the
> current release cycle information to only allow contract’s to
> occur at a set major release and maintain the column in the model
> till it is ready to be removed major release + 1 since the
> migration was added.
> Personally, for ease of development and functionality, I think the
> best option is the 3rd as it will not require reinventing the wheel
> around data loading and handling of already loaded data models that
> could affect ORM queries.
Well one advantage to the way "contract" is totally automated here is
that as long as the ORM models have a column X present, "contract" won't
remove it. What problem would storing the release cycle information
solve ? (also by "store" you mean a DB table? ).
I'm writing out a spec for Neutron this week that reboots the OSM
concept without dropping the concept of versioned migration files and
versioning as I've discussed. As I've mentioned elsewhere i hope to
enhance Alembic's functionality so that Nova's current OSM approach as
well as the file/ version-number based approach can both leverage the
same codebase for generating the stream of expand/contract steps.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev