On 13 February 2015 at 16:22, John Belamaric <[email protected]> wrote:
> > > From: Salvatore Orlando <[email protected]> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > Date: Friday, February 13, 2015 at 8:26 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
