<div dir="ltr">Hi,<div><br></div><div>Following up the latest GBP team meeting [0][1]:</div><div><br></div><div>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. </div><div><br></div><div>There are roughly a couple of possibilities for reaching this goal:</div><div><br></div><div>1) Using a separate DBs with separate migration chain;</div><div>2) Using the same DB with separate chain (and different alembic version table).</div><div><br></div><div>Personally I prefer the option 1, moving to a completely different database while leveraging cross database foreign keys.<br></div><div><br></div><div>Please let me know your preference, or alternative solutions! :)</div><div><br></div><div>Cheers,</div><div>Ivar.</div><div><br></div><div><span>[0] <a class="" href="http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-09-25-18.02.log.html">http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-09-25-18.02.log.html</a></span></div><div><span>[1] <a class="" href="http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-10-02-18.01.log.html">http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-10-02-18.01.log.html</a></span></div><div><span>[2] <a class="" href="https://github.com/stackforge/group-based-policy">https://github.com/stackforge/group-based-policy</a></span></div><div><span>[3] <a class="linkclass" href="https://review.openstack.org/#/c/123617/">https://review.openstack.org/#/c/123617/</a></span></div></div>