Open Stack

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

>
>
>  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.
>
>
>
>  Makes sense.
>
>
>>  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!
>
>
>
>  Yes, certainly. But it provides a transition period for plugins to
> migrate to support the new IPAM model.
>

I think we need to check Pavel's work on doing the plumbing for the IPAM
driver to assess whether it would be more convenient to have an IPAM base
class which extends and override DbBasePluginV2 or have 'ipam' versions of
methods in such class. In the latter case the approach wouldn't be too
different from the one you envisioned for classes, eg.:


if CONF.enable_ipam_drivers:
    self.create_port = self.create_port_ipam

(otherwise self.create_port would be the same method that we have today)

Salvatore


> __________________________________________________________________________
> 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/1e6250a8/attachment.html>