Open Stack

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
>
> 2. Some types do want to be the source of truth of the data stored,
> instead of it being the service plugin database.
>
>
> 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?

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.

2. I'm also considering that each plugin, which would be backend dependent,
could declare what features it supports through the use of extensions. 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.
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.


> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150818/c62ee2b8/attachment.html>