Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver
I am in favor not to go for a least common denominator approach with the bgpvpn API. The API should cover the use case commonly acknowledged as useful and which are supported by at least one of the existing back-ends, with the aim to have various back-ends to grow in support coverage. So then what is the goal of the bgpvpn project if every vendor-specific feature will be allowed through? Rather than being a generic way to setup BGP VPNs, it sounds to me like it will just become an HTTP proxy with Keystone authentication to vendor APIs. On Aug 21, 2015 11:26 PM, Jan Scheurich jan.scheur...@ericsson.com wrote: Hi all, I am in favor not to go for a least common denominator approach with the bgpvpn API. The API should cover the use case commonly acknowledged as useful and which are supported by at least one of the existing back-ends, with the aim to have various back-ends to grow in support coverage. Not supported features of the API could either be rejected by drivers, or a fallback behavior can be specified on API level in case a specific non-vital attribute is not supported by a backend (e.g. in the case of the RD). My preference would be to stick to the provider framework and to allow most backend-specific drivers to profit from the boilerplate code in the service plugin. BTW: The ODL plugin is planned to support both Network and Router association and the RD attribute will not be a mandatory attribute for the ODL back-end. Regards, Jan Mathieu Rohon Wed, 19 Aug 2015 06:46:45 -0700 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 __ 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
Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver
Hi all, I am in favor not to go for a least common denominator approach with the bgpvpn API. The API should cover the use case commonly acknowledged as useful and which are supported by at least one of the existing back-ends, with the aim to have various back-ends to grow in support coverage. Not supported features of the API could either be rejected by drivers, or a fallback behavior can be specified on API level in case a specific non-vital attribute is not supported by a backend (e.g. in the case of the RD). My preference would be to stick to the provider framework and to allow most backend-specific drivers to profit from the boilerplate code in the service plugin. BTW: The ODL plugin is planned to support both Network and Router association and the RD attribute will not be a mandatory attribute for the ODL back-end. Regards, Jan Mathieu Rohon Wed, 19 Aug 2015 06:46:45 -0700 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 __ 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
Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver
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
Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver
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
Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver
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-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
Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver
?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. 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. 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. 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.commailto: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
Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver
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 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.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
