What would be the best meeting to discuss these works and any others related? Maybe, collectively, a very flexible solution for all related use cases could be found.
I also want to go forward with some work I've developed a couple months ago, part of "methods to connect x to a neutron l2 segment", which aims at any "x", be it a 10-year old cheap home gateway wireless access point located at the other side of the planet, or a datacenter's hardware switch VLAN. Cheers, On 17 November 2014 12:29, Doug Wiegley <do...@a10networks.com> wrote: > Sorry, it's early, I was being imprecise and using trunk to mean, > "methods to connect x to a neutron (l2 segment". > > Doug > > On Nov 17, 2014, at 10:35 AM, Salvatore Orlando <sorla...@nicira.com> > wrote: > > 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 > > > _______________________________________________ > 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 <https://twitter.com/igordcard>
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev