Open Stack

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 <irenab.dev at gmail.com>
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 <
> salv.orlando at gmail.com> wrote:
>
>> my 0.02€ on the matter inline.
>>
>> Regards,
>> Salvatore
>>
>> On 18 August 2015 at 23:45, Mathieu Rohon <mathieu.rohon at gmail.com>
>> wrote:
>>
>>> hi brandon,
>>>
>>> thanks for your answer.
>>>
>>> my answers inline,
>>>
>>>
>>>
>>> On Tue, Aug 18, 2015 at 8:53 PM, Brandon Logan <
>>> brandon.logan at 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.rohon at 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.rohon at 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-request at 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-request at 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-request at 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-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/20150819/65fd6fb1/attachment.html>