On 7/15/15 9:26 AM, Ihar Hrachyshka wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, since it's a high impact change in the migration tree, I wanted to drop an email to everyone affected (basically, anyone who wants to introduce a new migration from now on). So there was a proposal to split migration rules into independent branches, with one 'expand' branch containing only those rules that are safe to apply while neutron-server is running. Proposal is at: http://specs.openstack.org/openstack/neutron-specs/specs/liberty/online- schema-migrations.html And the first patch to implement it just landed in neutron: http://git.openstack.org/cgit/openstack/neutron/commit/?id=c7acfbabdc13e d2a73bdbc6275af8063b8c1eb2f - From now on, - - there are multiple alembic heads for any database state; - - there is a new file structure under neutron/db/migration/versions/alembic_versions/{cycle}_{branch}; - - you may need to split your migrations into pieces (for expand and contract branches, respectively, depending on the character of schema changes; more details in the spec); - - 'neutron-db-manage upgrade head' still applies all heads; - - I'd like to rearrange migration trees for *aas repos in the same way, though neutron-db-manage still supports the old file layout. To get an example of how the split would look like for existing migration rules in review, I took Kevin's patch for RBAC: https://review.openstack.org/191707 And transformed it into something that adopts the new file layout: https://review.openstack.org/202013 Changes I made: - - split migration script into two pieces; - - updated HEADS file; - - made the contract phase script depends_on the expand one; Note that 'neutron-db-manage revision --autogenerate' command does not yet filter operations into corresponding branches, though we would like to have it in L once new alembic is released.
This API is in master and will be the focus of the 0.8 release. This is a major refactor so I'm still working out backwards-compatibility stuff as well as getting some more pluggability into autogenerate while we're at it. The documentation for the specific aspect of "filtering operations during autogenerate" is up at http://alembic.readthedocs.org/en/latest/api/autogenerate.html#customizing-revision-generation.
Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVpl92AAoJEC5aWaUY1u57EHoIALn4Q+k46liBJeto/pVZ+/Yd PYOJuuAV8jIrC1Xrg+70HDJ2W3TeioYAy+XqNLQ178P7cq2Gbn9xKOlzm8tuojtl dwc2cmtS443YI1IGe6Vcv9uQdYQ3qtdkuruGoaxGvIb7oRCZ9QF9qLdJELw4hG6z 8B2TSrpJ6aduudmkO+DUw9rcmyG6SNAEuXSdLPEkz9oIaVPvNODHA5D8VSN0xmNY kHRNFfXcdsLZ3IWqu/xsgIbujLBPcblgdl8Oofw4GaMA271sdGMPUgPl07nAnJqa WoyOER9VQz8DqnLpXOq36oZpmCrFc+Uk7SVbvyB4nZgB0OMkvQHdtzB/Tw2yCc8= =3nWE -----END PGP SIGNATURE----- __________________________________________________________________________ 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
__________________________________________________________________________ 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
