Open Stack

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 <dougw at 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 <sorlando at 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 <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
>>
>
>   _______________________________________________
> 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 <https://twitter.com/igordcard>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141117/adc05c61/attachment.html>