On Apr 14, 2014, at 11:54 AM, Salvatore Orlando <sorla...@nicira.com<mailto:sorla...@nicira.com>> wrote:
1) Specify that all migrations must run for every plugin (*) unless they are really introducing schemas which are specific to a particular technology (such as uuid mappings between neutron and backed) This approach will probably ensure all the important migrations are executed. However, it is not back portable, unless deployers decide to tear down and rebuild their databases from scratch, which is unlikely to happen. To this aim "recovery" scripts might be provided to sync up the schema state of specific service plugins with the current alembic migration registered in the neutron database; or appropriate migrations can be added in the path to fix database schemas. (*) Neutron does not address, and probably never will address, switching from plugin "a" to "b" for a given service (e.g.: core features). This option has several additional problems because of the way plugins/drivers are conditionally imported and packaged. As a result, auto generation of schema (inadvertent drop for schema) or even validation of existing models vs the the migration will fail because models are not imported unless part of the configuration. mark
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
