Open Stack

On Wed, Mar 30, 2016 at 9:03 AM, Pavel Bondar <pbondar at 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