On Mon, Nov 17, 2014 at 10:13:50AM +0100, Mathieu Rohon <mathieu.ro...@gmail.com> wrote:
> Hi 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. I, Isaku, talked with Maruti and has agreed to pursue [1] with a hope to unify [2] and we will see the outcome in kilo cycle. I'm willing to review/help [1] (and corresponding patches). thanks, > > 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. > > > 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 -- Isaku Yamahata <isaku.yamah...@gmail.com> _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
