Open Stack

On 19 November 2014 17:19, Sukhdev Kapur <sukhdevkapur at gmail.com> wrote:

> Folks,
>
> Like Ian, I am jumping in this very late as well - as I decided to travel
> Europe after the summit, just returned back and  catching up :-):-)
>
> I have noticed that this thread has gotten fairly convoluted and painful
> to read.
>
> I think Armando summed it up well in the beginning of the thread. There
> are basically three written proposals (listed in Armando's email - I pasted
> them again here).
>
> [1] https://review.openstack.org/#/c/134179/
> [2] https://review.openstack.org/#/c/100278/
> [3] https://review.openstack.org/#/c/93613/
>
> On this thread I see that the authors of first two proposals have already
> agreed to consolidate and work together. This leaves with two proposals.
> Both Ian and I were involved with the third proposal [3] and have
> reasonable idea about it. IMO, the use cases addressed by the third
> proposal are very similar to use cases addressed by proposal [1] and [2]. I
> can volunteer to  follow up with Racha and Stephen from Ericsson to see if
> their use case will be covered with the new combined proposal. If yes, we
> have one converged proposal. If no, then we modify the proposal to
> accommodate their use case as well. Regardless, I will ask them to review
> and post their comments on [1].
>
> Having said that, this covers what we discussed during the morning session
> on Friday in Paris. Now, comes the second part which Ian brought up in the
> afternoon session on Friday.
> My initial reaction was, when heard his use case, that this new
> proposal/API should cover that use case as well (I am being bit optimistic
> here :-)). If not, rather than going into the nitty gritty details of the
> use case, let's see what modification is required to the proposed API to
> accommodate Ian's use case and adjust it accordingly.
>

As far as I can see, the question of whether you mark a network as 'edge'
and therefore bridged to something you don't know about (my proposal) or
whether you attach a block to it that, behinds the scenes, bridges to
something you don't know about (Maruti's, if you take out all of the
details of *what* is being attached to from the API) are basically as good
as each other.

My API parallels the way that provider networks are used, because that's
what I had in mind at the time; Maruti's uses a block rather than marking
the network, and the only real difference that makes is that (a) you can
attach many networks to one block (which doesn't really seem to bring
anything special) and (b) uses a port to connect to the network (which is
not massively helpful because there's nothing sensible you can put on the
port; there may be many things behind the gateway).  At this point it
becomes a completely religious argument about which is better.  I still
prefer mine, from gut feel, but they are almost exactly equivalent at this
point.

Taking your statement above of 'let's take out the switch port stuff' then
Maruti's use case would need to explain where that data goes. The point I
made is that it becomes a Sisyphean task (endless and not useful) to
introduce a data model and API to introduce this into Neutron via an API
and that's what I didn't want to do.  Can we address that question?

-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141120/c8b5637a/attachment.html>