On 11 February 2016 at 20:17, John Belamaric <jbelama...@infoblox.com> wrote:
> > On Feb 11, 2016, at 12:04 PM, Armando M. <arma...@gmail.com> wrote: > > > > On 11 February 2016 at 07:01, John Belamaric <jbelama...@infoblox.com> > wrote: > >> >> >> >> It is only internal implementation changes. >> > > That's not entirely true, is it? There are config variables to change and > it opens up the possibility of a scenario that the operator may not care > about. > > > > If we were to remove the non-pluggable version altogether, then the > default for ipam_driver would switch from None to internal. Therefore, > there would be no config file changes needed. > I think this is correct. Assuming the migration path to Neutron will include the data transformation from built-in to pluggable IPAM, do we just remove the old code and models? On the other hand do you think it might make sense to give operators a chance to rollback - perhaps just in case some nasty bug pops up? What's the team level of confidence in the robustness of the reference IPAM driver? Salvatore > > > John > > > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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
