Open Stack

On 17 November 2014 01:13, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:

> 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.
>
> > 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.
>

I am not sure I agree with this statement. I am not aware of any proposal
here being dependent on external components as you suggested, but even if
it were, an API can be implemented in multiple ways, just like the (core)
Neutron API can be implemented using a fully open source solution or an
external party like an SDN controller.


> 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.
>

Right, but it seems we are struggling to find this consensus. In this
particular instance, where we are trying to address the use case of L2
Gateway (i.e. allow Neutron logical networks to be extended with physical
ones), it seems that everyone has a different opinion as to what
abstraction we should adopt in order to express and configure the L2
gateway entity, and at the same time I see no convergence in sight.

Now if the specific L2 Gateway case were to be considered part of the core
Neutron API, then such a consensus would be mandatory IMO, but if it isn't,
is there any value in striving for that consensus at all costs? Perhaps
not, and we can have multiple attempts experiment and innovate
independently.

So far, all my data points seem to imply that such an abstraction need not
be part of the core API.


> 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.
>

Advanced Services may be a misnomer, but an incubation feature, sure why
not?


>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141117/c5442542/attachment.html>