Open Stack

>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.scheurich at 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-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/20150823/dc5fbf2e/attachment.html>