Open Stack

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.

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 :)

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 <https://twitter.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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141114/5286ecd9/attachment.html>