On 30/03/16 16:08, Pavel Bondar wrote: > We are now in early Newton, so it is good time to discuss plan for > pluggable ipam for this release cycle. > > 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. > > Right now we have some open bugs for pluggable code [2], but they are > still possible to fix. > > Does it make sense to you?
Yes! Kill the non-pluggable code already. Neutron desperately needs to have less and simpler code in any area where it can possibly get it. Neil __________________________________________________________________________ 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