Open Stack

This is great! I'm not sure if you have been following some of the
discussion about the separation of vendor drivers in Neutron, but one of
the things we decided was to leave the vendor data models in the main repo
so we have a nice linear migration.
It looks like branching support may solve our problem. However, looking
through the docs I didn't notice anything about where the migration
definitions need to live. Can migrations be sourced from multiple locations
easily?

>is the so-called “degenerate” case (an odd term for me to use as I am so
not a math person).

I was always under the impression we used that term to make the person that
came up with the original use-case feel bad. :-)



On Fri, Nov 21, 2014 at 1:10 PM, Mike Bayer <mbayer at redhat.com> wrote:

> Hi all -
>
> I’d like to announce / give a prominent heads up that Alembic 0.7.0 is
> ready for release.  Over the past several weeks I’ve completed the initial
> implementations for two critical features, SQLite migrations and multiple
> branch/ merge support, as well as merged over a dozen bug fixes and smaller
> features.    This release is probably the most dramatic set of changes
> Alembic has had since some early refactorings long before Openstack was
> making use of it, and as such I think it’s appropriate to make sure that
> this is anticipated.
>
> Given that I’ve seen some grumbling about other projects recently
> releasing on weekends, assuming no new issues are found, I hope to release
> Alembic 0.7.0 on Sunday night or Monday.    I have run a subset of
> Openstack related tests as is part of my usual continuous environment,
> including all of oslo.db (there’s one test fix for oslo.db pending) as well
> as Neutron’s “neutron.tests.unit.db.test_migration” which if I understand
> it correctly exercises Alembic considerably.
>
> Version 0.7.0 includes a lot of tweaks and enhancements in the usual
> “autogenerate” category as well as to some operational directives, but most
> prominently includes multiple branch mode, a series of new commands and
> some changes to existing commands, as well as “batch mode” which is geared
> towards SQLite.     The SQLite batch mode enhancement exists as a new
> operational directive and series of behaviors that are optional, so code
> which doesn’t make explicit use of it will not be exposed to the new code.
> However the multiple branch/merge support involves a fundamental rewrite of
> the versioning system from the ground up.  It was implemented in such a way
> that there should be no backwards-compatibility problems of any kind -
> existing environments, script templates, migration scripts, and
> alembic_version tables will continue to work in the exact same manner as
> they did before, in the absence of using the newer branch features which
> introduces some mild changes to the workflow when used.   But the system
> does run on a new set of algorithms for which the currently supported use
> case of a “single linear stream of revisions” is the so-called “degenerate”
> case (an odd term for me to use as I am so not a math person).
>
> The release does not yet include two new features that I’d like to get in
> a subsequent release, maybe even 0.7.1 if things go smoothly, including Ann
> Kamyshnikova’s foreign key constraint autogeneration feature and a separate
> autogeneration feature for primary key constraints.
>
> To those out there wondering what steps to take, here they are:
>
> 1. read about the new features, particularly the branch support, and
> please let me know of any red flags/concerns you might have over the coming
> implementation, at
> http://alembic.readthedocs.org/en/latest/tutorial.html#running-batch-migrations-for-sqlite-and-other-databases
> and
> http://alembic.readthedocs.org/en/latest/tutorial.html#working-with-branches
> .
>
> 2. if your project uses Alembic already (I know Neutron does but I’m not
> sure who else yet), fire up a tox environment and install Alembic from
> master at https://github.com/zzzeek/alembic/, run the tests and please
> alert me to any breakages.
>
> 3. Keep a lookout for the release, and
>
> 4. don’t panic!   I’ve really tried to test this to a huge extent and if
> there are problems, I can fix them quickly.
>
> thanks all for reading!
>
> 0.7 changelog:
> http://alembic.readthedocs.org/en/latest/changelog.html#change-0.7.0
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141121/bbf506e5/attachment.html>