I think this thread is about the L2 gateway service... how's that related with the notion of trunk port?
I know that the spec under review adds a component which is tantamount to a L2 gateway, but while the functionality is similar, the use case, and therefore the API exposed, are rather different. Am I missing something here? Salvatore On 17 November 2014 10:40, Doug Wiegley <do...@a10networks.com> wrote: > > > On Nov 17, 2014, at 9:13 AM, 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. > > > >> 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. > > > > 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. > > To me, this is in the scope of the "advanced services" project. > > I think we need to be careful of the natural tendency to view the new > project as a place to put everything that is "moving too slowly" in > neutron. Certainly advanced services is one of the most obvious use cases > of this functionality, but that doesn't mean that the notion of an SDN > trunk port should live anywhere but neutron, IMO. > > Thanks, > doug > > > > >> Ultimately the biggest debate is on what the API model needs to be for > these > >> abstractions. We can judge on which one is the best API of all, but > >> sometimes this ends up being a religious fight. A good API for me might > not > >> be a good API for you, even though I strongly believe that a good API > is one > >> that can: > >> > >> - be hard to use incorrectly > >> - clear to understand > >> - does one thing, and one thing well > >> > >> So far I have been unable to be convinced why we'd need to cram more > than > >> one abstraction in one single API, as it does violate the above > mentioned > >> principles. Ultimately I like the L2 GW API proposed by 1 and 2 because > it's > >> in line with those principles. I'd rather start from there and iterate. > >> > >> My 2c, > >> Armando > >> > >> On 14 November 2014 08:47, Salvatore Orlando <sorla...@nicira.com> > wrote: > >>> > >>> Thanks guys. > >>> > >>> I think you've answered my initial question. Probably not in the way I > was > >>> hoping it to be answered, but it's ok. > >>> > >>> So now we have potentially 4 different blueprint describing more or > less > >>> overlapping use cases that we need to reconcile into one? > >>> If the above is correct, then I suggest we go back to the use case and > >>> make an effort to abstract a bit from thinking about how those use > cases > >>> should be implemented. > >>> > >>> Salvatore > >>> > >>> On 14 November 2014 15:42, Igor Cardoso <igordc...@gmail.com> wrote: > >>>> > >>>> Hello all, > >>>> Also, what about Kevin's https://review.openstack.org/#/c/87825/? > One of > >>>> its use cases is exactly the L2 gateway. These proposals could > probably be > >>>> inserted in a more generic work for moving existing datacenter L2 > resources > >>>> to Neutron. > >>>> Cheers, > >>>> > >>>> On 14 November 2014 15:28, Mathieu Rohon <mathieu.ro...@gmail.com> > wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> As far as I understood last friday afternoon dicussions during the > >>>>> design summit, this use case is in the scope of another umbrella spec > >>>>> which would define external connectivity for neutron networks. > Details > >>>>> of those connectivity would be defined through service plugin API. > >>>>> > >>>>> Ian do you plan to define such an umbrella spec? or at least, could > >>>>> you sum up the agreement of the design summit discussion in the ML? > >>>>> > >>>>> I see at least 3 specs which would be under such an umbrella spec : > >>>>> https://review.openstack.org/#/c/93329/ (BGPVPN) > >>>>> https://review.openstack.org/#/c/101043/ (Inter DC connectivity with > >>>>> VPN) > >>>>> https://review.openstack.org/#/c/134179/ (l2 gw aas) > >>>>> > >>>>> > >>>>> On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando < > sorla...@nicira.com> > >>>>> wrote: > >>>>>> Thanks Maruti, > >>>>>> > >>>>>> I have some comments and questions which I've posted on gerrit. > >>>>>> There are two things I would like to discuss on the mailing list > >>>>>> concerning > >>>>>> this effort. > >>>>>> > >>>>>> 1) Is this spec replacing https://review.openstack.org/#/c/100278 > and > >>>>>> https://review.openstack.org/#/c/93613 - I hope so, otherwise this > >>>>>> just adds > >>>>>> even more complexity. > >>>>>> > >>>>>> 2) It sounds like you should be able to implement this service > plugin > >>>>>> in > >>>>>> either a feature branch or a repository distinct from neutron. Can > you > >>>>>> confirm that? > >>>>>> > >>>>>> Salvatore > >>>>>> > >>>>>> On 13 November 2014 13:26, Kamat, Maruti Haridas < > maruti.ka...@hp.com> > >>>>>> wrote: > >>>>>>> > >>>>>>> Hi Friends, > >>>>>>> > >>>>>>> As discussed during the summit, I have uploaded the spec for > >>>>>>> review > >>>>>>> at https://review.openstack.org/#/c/134179/ > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Maruti > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Igor Duarte Cardoso. > >>>> http://igordcard.com > >>>> @igordcard > >>>> > >>>> _______________________________________________ > >>>> 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 > > > _______________________________________________ > 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