Open Stack

Hi Sukhdev,

Hope you enjoyed Europe ;)

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.
>
> Now, the last point (already brought up by Salvatore as well as Armando) -
> the abstraction of the API, so that it meets the Neutron API criteria. I
> think this is the critical piece. I also believe the API proposed by [1] is
> very close. We should clean it up and take out references to ToR's or
> physical vs virtual devices. The API should work at an abstract level so
> that it can deal with both physical as well virtual devices. If we can
> agree to that, I believe we can have a solid solution.
>

Yes, I do think that the same API can target both: a 100% software solution
for L2GW as well as one that may want to rely on hardware support, in the
same spirit of any other Neutron API. I made the same point on spec [1].


>
>
> Having said that I would like to request the community to review the
> proposal submitted by Maruti in [1] and post comments on the spec with the
> intent to get a closure on the API. I see lots of good comments already on
> the spec. Lets get this done so that we can have a workable (even if not
> perfect) version of API in Kilo cycle. Something which we can all start to
> play with. We can always iterate over it, and make change as we get more
> and more use cases covered.
>

So far it seems like proposal [1] that has the most momentum. I'd like to
consider [3] as one potential software implementation of the proposed API.
As I mentioned earlier, I'd rather start with a well defined problem, free
of any potential confusion or open to subjective interpretation; a loose
API suffers from both pitfalls, hence my suggestion to go with API proposed
in [1].


>
> Make sense?
>
> cheers..
> -Sukhdev
>
>
> On Tue, Nov 18, 2014 at 6:44 PM, Armando M. <armamig at gmail.com> wrote:
>
>> Hi,
>>
>> On 18 November 2014 16:22, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:
>>
>>> 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.)
>>>
>>
>> Ah! I hope it was good at least :)
>>
>>
>>>
>>> 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
>>>
>>
>> No disagreement all the way up to this point, assumed that I don't worry
>> about what this edge API really is.
>>
>>
>>> - 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.)
>>>
>>
>> This is where the disagreement begins, as far as I am concerned; in fact
>> we already have a well defined way of describing what a network entity in
>> Neutron is, namely an L2 broadcast domain abstraction. An L2 gateway API
>> that is well defined and well scoped should just express how one can be
>> connected to another, nothing more, at least as a starting point.
>>
>>
>>>
>>> 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.
>>>
>>
>> Well, that is true assumed that someone can or is willing to use them :)
>>
>>
>>>
>>>
>>>> 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.
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> 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/20141120/473a9230/attachment.html>