Open Stack

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 <dougw at a10networks.com> wrote:

>
> > On Nov 17, 2014, at 9:13 AM, 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.
> > 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 <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
>
>
> _______________________________________________
> 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/0422a41d/attachment.html>