Hi, Following up the latest GBP team meeting [0][1]: As we keep going with our Juno stackforge implementation [2], although the service is effectively a Neutron extension, we should avoid breaking Neutron's migration chain by adding our model on top of it (and subsequently changing Neutron's HEAD [3]). If we do that, upgrading from Juno to Kilo will be painful for those who have used GBP. There are roughly a couple of possibilities for reaching this goal: 1) Using a separate DBs with separate migration chain; 2) Using the same DB with separate chain (and different alembic version table). Personally I prefer the option 1, moving to a completely different database while leveraging cross database foreign keys. Please let me know your preference, or alternative solutions! :) Cheers, Ivar. [0] http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-09-25-18.02.log.html [1] http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-10-02-18.01.log.html [2] https://github.com/stackforge/group-based-policy [3] https://review.openstack.org/#/c/123617/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141003/74906c50/attachment.html>