Open Stack

On 13 February 2015 at 16:22, John Belamaric <jbelamaric at infoblox.com>
wrote:

>
>
>   From: Salvatore Orlando <sorlando at nicira.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Friday, February 13, 2015 at 8:26 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] Update on "DB" IPAM driver
>
>     ...
>>
>
>      I think the auto-generated case should be a base class as you
>> described in [1], but each subclass would implement the specific
>> auto-generation. See the discussion at line 468 in [2] and see what you
>> think. Of course for addresses that come from RA there would be no IPAM.
>>
>
>  I think this makes sense.
>
>
>
>  Thinking a little more on this, in the case of magic address prefixes,
> we probably should have the factory method generate the right request
> class. That way, the logic for those magic prefixes is all in one place.
> You could still specify the class in the request but the magic prefixes
> would take priority.
>

Put it in this way, it also makes sense. But I think I need to see it
translated in code to figure it out properly. Anyway, this is something
which pertains the base classes rather than the reference driver.
I think from the perspective of the reference driver we should just raise
if a "AnyAddressRequest" is sent for a subnet where addresses are supposed
to be autogenerated, because the ipam driver won't generate the address.


>
>
>
>>  [1] https://review.openstack.org/#/c/150485/
>>  [2]
>> https://review.openstack.org/#/c/153236/2/neutron/db/db_base_plugin_v2.py,unified
>>
>>
>
>
>>  - The db base refactoring being performed by Pavel is under way [3]. It
>> is worth noting that this is a non-negligible change to some of Neutron's
>> basic and more critical workflows. We should expect pushback from the
>> community regarding the introduction of this change in the 3rd milestone.
>> At this stage I would suggest either:
>> A) consider a strategy for running pluggable IPAM as optional
>> B) consider delaying to Liberty.
>> (and that's where I get virtually jeered and pelted with rotten tomatoes)
>>
>>
>>  I wish I had some old tomatoes! Seriously, I think "A" is a reasonable
>> approach. To make this really explicit we may want to basically replace the
>> DB plugin class with a shim that delegates to either the current
>> implementation or the new implementation, depending on the flag.
>>
>
>  The fact that the current implementation is pretty much a bunch of
> private methods in the db base plugin class executed within a transaction
> for creating a port makes the situation a wee bit more complex. I'm not
> sure we can replace the db plugin class with a shim so easily, because we
> need to consider the impact on plugins which inherit from this base class.
> For instance some plugins override methods from the base class, and this
> would be a problem. For those plugins we must ensure old-style IPAM is
> performed. A transitory solution might be to have, for the relevant methods
> 2 versions - one would be the current one, and the other one would be the
> one leveraging pluggable IPAM. During plugin initialisation, the plugin
> itself will decide whether use or not the latter methods. This might be
> tuneable with a configuration parameter too. The downside of this approach
> is that it will not allow us to remove "old" baked in IPAM code, and will
> have an impact on code maintainability which ultimately will result in
> accumulating even more technical debt. However, I might be missing some
> better alternative, so if you have any proposal just let me know.
>
>
>  Hmm. How dynamic is Python? I know in Ruby I could do something like
> this at class load time:
>
>  config.use_ipam ? DbBasePluginV2 = IpamDbBasePluginV2 : DbBasePluginV2 =
> LegacyDbBasePluginV2
>
>  and all the subclasses would work fine as before...
>

Technically yes.
>From a practical perspective however if the subclass is assuming that
create_port works in the "old" way, and then instead is working in the
"ipam" way, it might be mayhem!


>
>
>
> __________________________________________________________________________
> 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/20150213/aad5057f/attachment-0001.html>