Open Stack

On Mon, Nov 17, 2014 at 10:13:50AM +0100,
Mathieu Rohon <mathieu.rohon at gmail.com> wrote:

> Hi

Hi.


> On Fri, Nov 14, 2014 at 6:26 PM, Armando M. <armamig at 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 <sorlando at 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 <igordcard at 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.rohon at 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 <sorlando at 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.kamat at 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 at lists.openstack.org
> >>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>> >>
> >>>> >
> >>>> >
> >>>> > _______________________________________________
> >>>> > OpenStack-dev mailing list
> >>>> > OpenStack-dev at lists.openstack.org
> >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>> >
> >>>>
> >>>> _______________________________________________
> >>>> OpenStack-dev mailing list
> >>>> OpenStack-dev at 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 at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Isaku Yamahata <isaku.yamahata at gmail.com>