Hi Sukhdev, Hope you enjoyed Europe ;)
On 19 November 2014 17:19, Sukhdev Kapur <sukhdevka...@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. <arma...@gmail.com> wrote: > >> Hi, >> >> On 18 November 2014 16:22, Ian Wells <ijw.ubu...@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.ro...@gmail.com> >>> wrote: >>> >>>> Hi >>>> >>>> On Fri, Nov 14, 2014 at 6:26 PM, Armando M. <arma...@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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev