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). > >  https://review.openstack.org/#/c/134179/ >  https://review.openstack.org/#/c/100278/ >  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  and have > reasonable idea about it. IMO, the use cases addressed by the third > proposal are very similar to use cases addressed by proposal  and . 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 . > > 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.
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev