Open Stack

Salvatore Orlando <salv.orlando at gmail.com> wrote:

> On 11 February 2016 at 20:17, John Belamaric <jbelamaric at infoblox.com>  
> wrote:
>
>> On Feb 11, 2016, at 12:04 PM, Armando M. <armamig at gmail.com> wrote:
>>
>>
>>
>> On 11 February 2016 at 07:01, John Belamaric <jbelamaric at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev