Open Stack

Sorry I'm a bit late to this, but that's what you get from being on
holiday...  (Which is also why there are no new MTU and VLAN specs yet, but
I swear I'll get to them.)

On 17 November 2014 01:13, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:

> Hi
>
> On Fri, Nov 14, 2014 at 6:26 PM, Armando M. <armamig at gmail.com> wrote:
> > Last Friday I recall we had two discussions around this topic. One in the
> > morning, which I think led to Maruti to push [1]. The way I understood
> [1]
> > was that it is an attempt at unifying [2] and [3], by choosing the API
> > approach of one and the architectural approach of the other.
> >
> > [1] https://review.openstack.org/#/c/134179/
> > [2] https://review.openstack.org/#/c/100278/
> > [3] https://review.openstack.org/#/c/93613/
> >
> > Then there was another discussion in the afternoon, but I am not 100% of
> the
> > outcome.
>
> Me neither, that's why I'd like ian, who led this discussion, to sum
> up the outcome from its point of view.
>

So, the gist of what I said is that we have three, independent, use cases:

- connecting two VMs that like to tag packets to each other (VLAN clean
networks)
- connecting many networks to a single VM (trunking ports)
- connecting the outside world to a set of virtual networks

We're discussing that last use case here.  The point I was made was that:

- there are more encaps in the world than just VLANs
- they can all be solved in the same way using an edge API
- if they are solved using an edge API, the job of describing the network
you're trying to bring in (be it switch/port/vlan, or MPLS label stack, or
l2tpv3 endpoint data) is best kept outside of Neutron's API, because
Neutron can't usefully do anything with it other than validate it and hand
it off to whatever network control code is being used.  (Note that most
encaps will likely *not* be implemented in Neutron's inbuilt control code.)

Now, the above argument says that we should keep this out of Neutron.  The
problem with that is that people are using the OVS mechanism driver and
would like a solution that works with that, implying something that's
*inside* Neutron.  For that case, it's certainly valid to consider another
means of implementation, but it wouldn't be my personal choice.  (For what
it's worth I'm looking at ODL based controller implementations, so this
isn't an issue for me personally.)

If one were to implement the code in the Neutron API, even as an extension,
I would question whether it's a sensible thing to attempt before the RPC
server/REST server split is done, since it also extends the API between
them.

> All this churn makes me believe that we probably just need to stop
> > pretending we can achieve any sort of consensus on the approach and let
> the
> > different alternatives develop independently, assumed they can all
> develop
> > independently, and then let natural evolution take its course :)
>
> I tend to agree, but I think that one of the reason why we are looking
> for a consensus, is because API evolutions proposed through
> Neutron-spec are rejected by core-dev, because they rely on external
> components (sdn controller, proprietary hardware...) or they are not a
> high priority for neutron core-dev.
> By finding a consensus, we show that several players are interested in
> such an API, and it helps to convince core-dev that this use-case, and
> its API, is missing in neutron.
>

There are lots of players interested in an API, that much is clear, and all
the more so if you consider that this feature has strong analogies with use
cases such as switch port exposure and MPLS.  The problem is that it's
clearly a fairly complex API with some variety of ways to implement it, and
both of these things work against its acceptance.  Additionally, per the
above discussion, I would say it's not essential for it to be core Neutron
functionality.

Now, if there is room for easily propose new API in Neutron, It make
> sense to leave new API appear and evolve, and then " let natural
> evolution take its course ", as you said.
>

Natural selection works poorly on APIs because once they exist they're hard
to change and/or retire, due to backward compatibility requirements.


> To me, this is in the scope of the "advanced services" project.
>

Advanced services or no, the point I was making is that this is not
something that should fit under the Neutron API endpoint.  Since it's not
really related to any of the other advanced services it's not particularly
necessary that it fit under the Advanced Services API endpoint either,
although it could.  My Unix design leanings say to me that if things are
not related they shouldn't be combined, though - the simplest thing that
does the job is the right answer.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141118/2b550907/attachment.html>