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