<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 17 November 2014 01:13, Mathieu Rohon <span dir="ltr"><<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<span><br>
On Fri, Nov 14, 2014 at 6:26 PM, Armando M. <<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>> wrote:<br>
> Last Friday I recall we had two discussions around this topic. One in the<br>
> morning, which I think led to Maruti to push [1]. The way I understood [1]<br>
> was that it is an attempt at unifying [2] and [3], by choosing the API<br>
> approach of one and the architectural approach of the other.<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/134179/" target="_blank">https://review.openstack.org/#/c/134179/</a><br>
> [2] <a href="https://review.openstack.org/#/c/100278/" target="_blank">https://review.openstack.org/#/c/100278/</a><br>
> [3] <a href="https://review.openstack.org/#/c/93613/" target="_blank">https://review.openstack.org/#/c/93613/</a><br>
><br>
> Then there was another discussion in the afternoon, but I am not 100% of the<br>
> outcome.<br>
<br>
</span>Me neither, that's why I'd like ian, who led this discussion, to sum<br>
up the outcome from its point of view.<br>
<span><br>
> All this churn makes me believe that we probably just need to stop<br>
> pretending we can achieve any sort of consensus on the approach and let the<br>
> different alternatives develop independently, assumed they can all develop<br>
> independently, and then let natural evolution take its course :)<br>
<br>
</span>I tend to agree, but I think that one of the reason why we are looking<br>
for a consensus, is because API evolutions proposed through<br>
Neutron-spec are rejected by core-dev, because they rely on external<br>
components (sdn controller, proprietary hardware...) or they are not a<br>
high priority for neutron core-dev.<br></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
By finding a consensus, we show that several players are interested in<br>
such an API, and it helps to convince core-dev that this use-case, and<br>
its API, is missing in neutron.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So far, all my data points seem to imply that such an abstraction need not be part of the core API.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Now, if there is room for easily propose new API in Neutron, It make<br>
sense to leave new API appear and evolve, and then " let natural<br>
evolution take its course ", as you said.<br>
To me, this is in the scope of the "advanced services" project.<br></blockquote><div><br></div><div>Advanced Services may be a misnomer, but an incubation feature, sure why not?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
> Ultimately the biggest debate is on what the API model needs to be for these<br>
> abstractions. We can judge on which one is the best API of all, but<br>
> sometimes this ends up being a religious fight. A good API for me might not<br>
> be a good API for you, even though I strongly believe that a good API is one<br>
> that can:<br>
><br>
> - be hard to use incorrectly<br>
> - clear to understand<br>
> - does one thing, and one thing well<br>
><br>
> So far I have been unable to be convinced why we'd need to cram more than<br>
> one abstraction in one single API, as it does violate the above mentioned<br>
> principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's<br>
> in line with those principles. I'd rather start from there and iterate.<br>
><br>
> My 2c,<br>
> Armando<br>
><br>
> On 14 November 2014 08:47, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> wrote:<br>
>><br>
>> Thanks guys.<br>
>><br>
>> I think you've answered my initial question. Probably not in the way I was<br>
>> hoping it to be answered, but it's ok.<br>
>><br>
>> So now we have potentially 4 different blueprint describing more or less<br>
>> overlapping use cases that we need to reconcile into one?<br>
>> If the above is correct, then I suggest we go back to the use case and<br>
>> make an effort to abstract a bit from thinking about how those use cases<br>
>> should be implemented.<br>
>><br>
>> Salvatore<br>
>><br>
>> On 14 November 2014 15:42, Igor Cardoso <<a href="mailto:igordcard@gmail.com" target="_blank">igordcard@gmail.com</a>> wrote:<br>
>>><br>
>>> Hello all,<br>
>>> Also, what about Kevin's <a href="https://review.openstack.org/#/c/87825/" target="_blank">https://review.openstack.org/#/c/87825/</a>? One of<br>
>>> its use cases is exactly the L2 gateway. These proposals could probably be<br>
>>> inserted in a more generic work for moving existing datacenter L2 resources<br>
>>> to Neutron.<br>
>>> Cheers,<br>
>>><br>
>>> On 14 November 2014 15:28, Mathieu Rohon <<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> As far as I understood last friday afternoon dicussions during the<br>
>>>> design summit, this use case is in the scope of another umbrella spec<br>
>>>> which would define external connectivity for neutron networks. Details<br>
>>>> of those connectivity would be defined through service plugin API.<br>
>>>><br>
>>>> Ian do you plan to define such an umbrella spec? or at least, could<br>
>>>> you sum up the agreement of the design summit discussion in the ML?<br>
>>>><br>
>>>> I see at least 3 specs which would be under such an umbrella spec :<br>
>>>> <a href="https://review.openstack.org/#/c/93329/" target="_blank">https://review.openstack.org/#/c/93329/</a> (BGPVPN)<br>
>>>> <a href="https://review.openstack.org/#/c/101043/" target="_blank">https://review.openstack.org/#/c/101043/</a> (Inter DC connectivity with<br>
>>>> VPN)<br>
>>>> <a href="https://review.openstack.org/#/c/134179/" target="_blank">https://review.openstack.org/#/c/134179/</a> (l2 gw aas)<br>
>>>><br>
>>>><br>
>>>> On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>><br>
>>>> wrote:<br>
>>>> > Thanks Maruti,<br>
>>>> ><br>
>>>> > I have some comments and questions which I've posted on gerrit.<br>
>>>> > There are two things I would like to discuss on the mailing list<br>
>>>> > concerning<br>
>>>> > this effort.<br>
>>>> ><br>
>>>> > 1) Is this spec replacing <a href="https://review.openstack.org/#/c/100278" target="_blank">https://review.openstack.org/#/c/100278</a> and<br>
>>>> > <a href="https://review.openstack.org/#/c/93613" target="_blank">https://review.openstack.org/#/c/93613</a> - I hope so, otherwise this<br>
>>>> > just adds<br>
>>>> > even more complexity.<br>
>>>> ><br>
>>>> > 2) It sounds like you should be able to implement this service plugin<br>
>>>> > in<br>
>>>> > either a feature branch or a repository distinct from neutron. Can you<br>
>>>> > confirm that?<br>
>>>> ><br>
>>>> > Salvatore<br>
>>>> ><br>
>>>> > On 13 November 2014 13:26, Kamat, Maruti Haridas <<a href="mailto:maruti.kamat@hp.com" target="_blank">maruti.kamat@hp.com</a>><br>
>>>> > wrote:<br>
>>>> >><br>
>>>> >> Hi Friends,<br>
>>>> >><br>
>>>> >> As discussed during the summit, I have uploaded the spec for<br>
>>>> >> review<br>
>>>> >> at <a href="https://review.openstack.org/#/c/134179/" target="_blank">https://review.openstack.org/#/c/134179/</a><br>
>>>> >><br>
>>>> >> Thanks,<br>
>>>> >> Maruti<br>
>>>> >><br>
>>>> >><br>
>>>> >><br>
>>>> >><br>
>>>> >> _______________________________________________<br>
>>>> >> OpenStack-dev mailing list<br>
>>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>> >><br>
>>>> ><br>
>>>> ><br>
>>>> > _______________________________________________<br>
>>>> > OpenStack-dev mailing list<br>
>>>> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>> ><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Igor Duarte Cardoso.<br>
>>> <a href="http://igordcard.com" target="_blank">http://igordcard.com</a><br>
>>> @igordcard<br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>