[openstack-dev] [Neutron] Run migrations for service plugins every time

Anna Kamyshnikova akamyshnikova at mirantis.com
Wed Apr 30 12:16:51 UTC 2014


Hi everyone!

I'm working on blueprint
https://blueprints.launchpad.net/neutron/+spec/neutron-robust-db-migrations.
This topic was discussed earlier by Salvatore in ML thread "Migrations,
service plugins and Grenade jobs". I'm researching how to make migrations
for service plugins run unconditionally. In fact it is enough to change
should_run method for migrations -  to make it return True if this
migration is for service plugin
https://review.openstack.org/#/c/91323/1/neutron/db/migration/__init__.py.
It is almost working except for conflicts of VNPaaS service plugin with
Brocade and Nuage plugins http://paste.openstack.org/show/77946/.
1) Migration for Brocade plugin fails, because 2c4af419145b_l3_support
doesn't run (it adds necessary table 'routers') It can be fixed by adding
Brocade plugin to list migration_for_plugins in 2c4af419145b_l3_support.
2) Migration for Nuage plugin fails, because e766b19a3bb_nuage_initial runs
after 52ff27f7567a_support_for_vpnaas, and there is no necessary table
'routers'.  It can be fixed by adding Nuage plugin to list
migration_for_plugins in 2c4af419145b_l3_support and removing addition of
these tables in e766b19a3bb_nuage_initial.

Also I researched opportunity to make all migrations run unconditionally,
but this could not be done as there is going to be a lot of conflicts
http://paste.openstack.org/show/77902/. Mostly this conflicts take place in
initial migrations for core plugins as they create basical tables that was
created before. For example, mlnx_initial create tables securitygroups,
securitygroupportbindings, networkdhcpagentbindings, portbindingports that
were already created in 3cb5d900c5de_securitygroups,
4692d074d587_agent_scheduler, 176a85fc7d79_add_portbindings_db migrations.
Besides I was thinking about 'making migrations smart' - to make them check
whether all necessary migrations has been run or not, but the main problem
about that is we need to store information about applied migrations, so
this should have been planned from the very beginning.

I look forward for any suggestions or thoughts on this topic.

Regards, Ann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140430/4b5a0b61/attachment.html>


More information about the OpenStack-dev mailing list