On Wed, Mar 30, 2016 at 9:03 AM, Pavel Bondar <pbon...@infoblox.com> wrote: > Kevin Benton commented on review page for current migration to pluggable > approach [1]: > > IMO this cannot be optional. It's going to be a nightmare to try to support > two IPAM systems that people may have switched between at various points in > time. I would much rather go all-in on the upgrade by making it automatic > with alembic and removing the option to use the legacy IPAM code completely. > > I've already been bitten by testing the new IPAM code with the config option > and switching back which resulted in undeletable subnets. Now we can always > yell at anyone that changes the config option like I did, but it takes a lot > of energy to yell at users and they don't care for it much. :) > > Even ignoring the support issue, consider schema changes. This migration > script will have to be constantly updated to work with whatever the current > state of the schema is on both sets of ipam tables. Without constant in-tree > testing enforcing that, we are one schema change away from this script > breaking. > > So let's bite the bullet and make this a normal contract migration. Either > the new ipam system is stable enough for us to commit to supporting it and > fix whatever bugs it may have, or we need to remove it from the tree. > Supporting both systems is unsustainable. > > This sound reasonable to me. It simplify support and testing (testing both > implementations in gate with full coverage is not easy). > From user prospective there should be no visible changes between pluggable > ipam and non-pluggable. > And making switch early in release cycle gives us enough time to fix any bug > we will find in pluggable implementation.
This is what I want too but some people wanted to allow choice. > Right now we have some open bugs for pluggable code [2], but they are still > possible to fix. Yes, we've got to fix this one but I think we have a way forward. I'm actually going to be working in IPAM for the next week or two on work related to the thread I posted to yesterday [3]. Maybe I could help out with this. Could you get this migration lined up in review and then we'll tackle the bugs as a joint effort? Hopefully we can make the switch before summit. Carl > Does it make sense to you? > > [1] https://review.openstack.org/#/c/277767/ > [2] https://bugs.launchpad.net/neutron/+bug/1543094 [3] http://lists.openstack.org/pipermail/openstack-dev/2016-March/090748.html __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
