Open Stack

On 12.02.2016 15:01, Ihar Hrachyshka wrote:
> 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.
>
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?

[1] https://review.openstack.org/#/c/277767/
[2] https://bugs.launchpad.net/neutron/+bug/1543094
>> 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
>
>
> __________________________________________________________________________
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160330/ccbba392/attachment.html>