Salvatore Orlando <salv.orla...@gmail.com> wrote:
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?
They can always revert to a previous release. And if we enable the new
implementation start of Newton, we’ll have enough time to fix bugs that
will pop up in gate.
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
__________________________________________________________________________
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
