Open Stack

One reason for trying to get an more complete API into Neutron is to have a standardized API. So users know what to expect and for providers to have something to comply to. Do you suggest we bring this standardization work to some other forum, OPNFV for example? Neutron provides low level hooks and the rest is defined elsewhere. Maybe this could work, but there would probably be other issues if the actual implementation is not on the edge or outside Neutron.

/Erik


From: Ian Wells [mailto:ijw.ubuntu at cack.org.uk]
Sent: den 4 december 2014 20:19
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

On 1 December 2014 at 21:26, Mohammad Hanif <mhanif at brocade.com<mailto:mhanif at brocade.com>> wrote:
I hope we all understand how edge VPN works and what interactions are introduced as part of this spec.  I see references to neutron-network mapping to the tunnel which is not at all case and the edge-VPN spec doesn’t propose it.  At a very high level, there are two main concepts:

  1.  Creation of a per tenant VPN “service” on a PE (physical router) which has a connectivity to other PEs using some tunnel (not known to tenant or tenant-facing).  An attachment circuit for this VPN service is also created which carries a “list" of tenant networks (the list is initially empty) .
  2.  Tenant “updates” the list of tenant networks in the attachment circuit which essentially allows the VPN “service” to add or remove the network from being part of that VPN.
A service plugin implements what is described in (1) and provides an API which is called by what is described in (2).  The Neutron driver only “updates” the attachment circuit using an API (attachment circuit is also part of the service plugin’ data model).   I don’t see where we are introducing large data model changes to Neutron?

Well, you have attachment types, tunnels, and so on - these are all objects with data models, and your spec is on Neutron so I'm assuming you plan on putting them into the Neutron database - where they are, for ever more, a Neutron maintenance overhead both on the dev side and also on the ops side, specifically at upgrade.

How else one introduces a network service in OpenStack if it is not through a service plugin?

Again, I've missed something here, so can you define 'service plugin' for me?  How similar is it to a Neutron extension - which we agreed at the summit we should take pains to avoid, per Salvatore's session?
And the answer to that is to stop talking about plugins or trying to integrate this into the Neutron API or the Neutron DB, and make it an independent service with a small and well defined interaction with Neutron, which is what the edge-id proposal suggests.  If we do incorporate it into Neutron then there are probably 90% of Openstack users and developers who don't want or need it but care a great deal if it breaks the tests.  If it isn't in Neutron they simply don't install it.

As we can see, tenant needs to communicate (explicit or otherwise) to add/remove its networks to/from the VPN.  There has to be a channel and the APIs to achieve this.

Agreed.  I'm suggesting it should be a separate service endpoint.
--
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141205/7a2c2584/attachment.html>