Current VPNaaS Service Plugin inherits from VpnPluginRpcDbMixin, which is not required for some vendor solutions, since L3 is implemented without leveraging L3 Agents to manage router namespaces (ODL, MidoNet, etc). I guess if Mixin usage will be changed to conditional RPC support based on drivers requirements, follow what Salvatore suggested makes perfect sense.
On Wed, Aug 19, 2015 at 11:06 AM, Salvatore Orlando <salv.orla...@gmail.com> wrote: > my 0.02€ on the matter inline. > > Regards, > Salvatore > > On 18 August 2015 at 23:45, Mathieu Rohon <mathieu.ro...@gmail.com> wrote: > >> hi brandon, >> >> thanks for your answer. >> >> my answers inline, >> >> >> >> On Tue, Aug 18, 2015 at 8:53 PM, Brandon Logan < >> brandon.lo...@rackspace.com> wrote: >> >>> So let me make sure I understand this. You want to do a separate >>> service plugin for what would normally be separate drivers under one >>> service plugin. The reasons for this are: >>> >>> >>> 1. You dont want users the ability to choose the type, you want it >>> always to be the same one >>> >> While in theory it is be possible to have multiple BGPVPN providers in > the same deployment, there are control and data plane aspects that the > service type framework at the moment cannot deal with it. Mathieu brought > some examples in the bug report. The bottom line appears to be that the > choice of the l3 service plugin (or whatever serves l3 in your deployment) > also dictates the choiche of the BGPVPN service provider to employ. > >> 2. Some types do want to be the source of truth of the data stored, >>> instead of it being the service plugin database. >>> >> This point has little to do with service types. It's about the fact that > plugins are not required to implemented the various db mixins in neutron.db > and therefore not required to use the neutron DB. > >> >>> First, let me address the possibility of a solution using one service >>> plugin and multiple drivers per type: >>> >>> >>> I think that you can overcome #1 in the instantiation of the service >>> plugin to check if there are more than 1 provider active, if so you can >>> just throw an exception saying you can only have 1. I'd have to look at it >>> more to see if there are any caveats to this, but I think that would work. >>> >>> >>> For #2, assuming #1 works, then the drivers that are defined can have >>> some boolean that they set that will tell the plugin whether they are the >>> source of truth or not, and depending on that you can store the data in the >>> service plugin's db or just pass the data along, also pass GET requests to >>> the drivers as well. >>> >>> >> I agree that those workarounds will surely works but I wonder what is the >> meaning of a service plugin/type that can only support one service >> provider? can't the service plugin be the service provider directly? >> > > I believe there is some value, but I am not able to quantify it at the > moment. > - A single service plugin also implies (more or less) a common user-facing > APIs. I really don't want to end up in a conditons where the user API looks > different (or the workflow is different) according to what's backing the > neutron BGPVPN implementation > - A single service plugin provides a commonplace for all the boilerplate > management logic. This works for most drivers, but not for those who don't > rely on neutron DB as a data source (unless you manage to build a > sqlalchemy dialect for things such as opencontrail APIs, but I seriously > doubt that it would be feasible) > - Distinct service plugins might lead to different workflows. This is not > necessarily a bad thing, because integration for some backends might need > it. However this means that during review phase particular attention should > be paid to ensure the behaviour of each service plugin respects the API > specification. > > >> >> The reasons why I'm considering this change are : >> >> 1. I'm not sure we would have some use cases where we would be able to >> choose one bgpvpn backend independently from the provider of the core >> plugin (or a mech driver in the ML2 case) and/or the router plugin. >> If one use ODL to manage its core resources, he won't be able to use >> nuage or contrail to manage its bgpvpn connection. >> The bgpvpn project is more about having a common API than having the >> capacity to mix backends. At least for the moment. >> > > I agree with this; but this problem exists regardless of whether you have > a single service plugin with drivers or multiple service plugins. You are > unlikely to be able to use the contrail BGPVPN service plugin is core and > l3 are managed by ODL, I think. > > >> >> 2. I'm also considering that each plugin, which would be backend >> dependent, could declare what features it supports through the use of >> extensions. >> > > Unfortunately extensions are the only way to declare supported > capabilities at the moment. But please - don't end up allowing each service > plugin exposing a different API. > > >> Each plugin would be a "bgpvpn" service type, and would implement the >> bgpvpn extension, but some of them could extend the bgpvpn_connection >> resource with other extensions also hosted in the bgpvpn project. Since >> some backends only support attachment of networks to a bgpvpn_connection, >> others support attachment of routers, and others both attachments, I'm >> considering having an extension for each type of attachment. Then the >> bgpvpn plugin declares what extensions it supports and the end user can act >> accordingly depending on the scan of neutron extensions. >> > > This is not good. It appears that you are forced to leak backend details > to API consumers. Is it possible for you to share more context on why this > is necessary and there's nothing that can be done to avoid it? > > > >> By moving to one plugin per backend, the load of extensions would be done >> by the neutron framework, natively. We won't have to scan each service >> providers to see what extensions it supports, as it is done by the ML2 >> extension manager. >> But I agree that with your workaround, of allowing only one service >> provider, we can easily scan this driver for its extensions. >> > > Indeed. But still, backends like contrail will have to provide their own > service plugin I think. Which might be ok. All the backends which leverage > the neutron DB might use the "driverized" plugin, and the others can supply > their own service plugin. > >> >> >>> As for making a service plugin for each type, I don't see why that >>> wouldn't work. It seems a bit overkill to me though because you'd probably >>> end up having 2 base classes for every service plugin type, one for using >>> the service plugin database and another for the data source of truth being >>> external. Probably a better way to do this, I'm sure I'm oversimplifying. >>> >> You're right, and you're not oversimplifying. With this change, the >> bgpvpn framework will only manage API extensions and the DB layer if >> needed. And we don't want this framework to be complicated, in a first >> step, we just want to have a consistent API for every backends. >> > I don't see much technical reasons why you couldn't do this, though. It's >>> just inconsistent and might cause some confusion. I'd need to spend some >>> time on it to really have an educated opinion. >>> >> The fact that this change will lead to inconsistency between usage of >> each service plugins is a valid point and might be enough to not do it and >> instead limiting the bgpvpn service plugin to be able to only load one >> service driver for the moment. Which is also inconsistent with some other >> service plugins, but probably less. >> >> thanks brandon. >> >> Mathieu >> >> Thanks, >>> Brandon >>> ------------------------------ >>> *From:* Mathieu Rohon <mathieu.ro...@gmail.com> >>> *Sent:* Tuesday, August 18, 2015 7:13 AM >>> *To:* OpenStack Development Mailing List >>> *Subject:* [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service >>> driver >>> >>> Adding the related subject :) >>> >>> On Tue, Aug 18, 2015 at 10:35 AM, Mathieu Rohon <mathieu.ro...@gmail.com >>> > wrote: >>> >>>> Hi all, >>>> >>>> The current bgpvpn implementation is using the service type framework, >>>> with a service plugin and one or more service providers. >>>> >>>> After registering the bug [1], I wonder if we would rather use a >>>> service plugin per implementation type (bagpipe, ODL, OpenContrail, >>>> Nuage...) which handles API calls, instead of having one service plugin >>>> which forwards API calls to a service driver depending on the provider >>>> chosen by the end user. >>>> >>>> I would like to better understand what would be the main drawbacks of >>>> such a move apart from the fact that a deployment would be tightly coupled >>>> to a bgpvpn plugin, and multiple implementations of the plugin couldn't >>>> coexist. >>>> >>>> Thanks, >>>> >>>> Mathieu >>>> >>>> [1]https://bugs.launchpad.net/bgpvpn/+bug/1485515 >>>> >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
