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 <[email protected]> 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:[email protected]] > *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 <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
