Open Stack

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 
> contract.
>
> 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...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150615/11b925cd/attachment.html>