<div dir="ltr"><div>Hi everyone!</div><div><br></div><div>I'm working on blueprint <a href="https://blueprints.launchpad.net/neutron/+spec/neutron-robust-db-migrations">https://blueprints.launchpad.net/neutron/+spec/neutron-robust-db-migrations</a>. 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 <a href="https://review.openstack.org/#/c/91323/1/neutron/db/migration/__init__.py">https://review.openstack.org/#/c/91323/1/neutron/db/migration/__init__.py</a>. </div>
<div>It is almost working except for conflicts of VNPaaS service plugin with Brocade and Nuage plugins <a href="http://paste.openstack.org/show/77946/">http://paste.openstack.org/show/77946/</a>. </div><div>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.</div>
<div>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.</div>
<div><br></div><div>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 <a href="http://paste.openstack.org/show/77902/">http://paste.openstack.org/show/77902/</a>. 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.</div>
<div><br></div><div>I look forward for any suggestions or thoughts on this topic.</div><div><br></div><div>Regards, Ann</div></div>