Open Stack

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