Open Stack

I have no problem with standardising the API, and I would suggest that a
service that provided nothing but endpoints could be begun as the next
phase of 'advanced services' broken out projects to standardise that API.
I just don't want it in Neutron itself.

On 5 December 2014 at 00:33, Erik Moe <erik.moe at ericsson.com> wrote:

>
>
> 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> 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.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20141205/a58c64b0/attachment.html>