Open Stack

On 1 December 2014 at 21:26, Mohammad Hanif <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/20141204/3ce598b9/attachment.html>