Open Stack

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

> On Nov 17, 2014, at 9:13 AM, Mathieu Rohon <mathieu.rohon at gmail.com<mailto:mathieu.rohon at gmail.com>> wrote:
>
> Hi
>
> On Fri, Nov 14, 2014 at 6:26 PM, Armando M. <armamig at gmail.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/699d2fad/attachment.html>