Hi, thanks for your reply irena and salvatore.
Currently, we're targeting 4 backends : bagpipe (the ref impelmentations compatible with other ref implementations of neutron), ODL, contrail and nuage. Contrail and bagpipe work with networks attachments to a bgpvpn connection, while ODL and Nuage work with routers attachments. We even start thinking about port attachments [1] Moreover, ODL needs a RD attribute that won't be supported by other backends. I think that each backend should be able to manage each kind of attachment in the future, depending on the will of the backend dev team. But in a firts step, we have to manage the capacity of each backend. So, indeed, the managment of attachments to a bgpvpn connection through the use of extensions will expose backend capacity. And I agree that it's not the good way, since when moving from one cloud to another, the API will change depending on the backend. So I see two ways to solve this issue : 1-In first releases, backends that don't support a feature will through a '"NotImplemented" exception when the feature will be called through the API; We still have an inconsistent API, but hopefully, this gone be temporary. 2-reducing the scope of the spec [2] and having less compatible backends, and a smaller community for the bgpvpn project. [1]https://blueprints.launchpad.net/bgpvpn/+spec/port-association [2]https://review.openstack.org/#/c/177740/ regards, Mathieu On Wed, Aug 19, 2015 at 1:55 PM, Irena Berezovsky <[email protected]> wrote: > 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 < > [email protected]> wrote: > >> my 0.02€ on the matter inline. >> >> Regards, >> Salvatore >> >> On 18 August 2015 at 23:45, Mathieu Rohon <[email protected]> >> wrote: >> >>> hi brandon, >>> >>> thanks for your answer. >>> >>> my answers inline, >>> >>> >>> >>> On Tue, Aug 18, 2015 at 8:53 PM, Brandon Logan < >>> [email protected]> 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 <[email protected]> >>>> *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 < >>>> [email protected]> 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: >>>> [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 >>> >>> >> >> __________________________________________________________________________ >> 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 > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
