Open Stack

On 07/31/2015 01:45 AM, Armando M. wrote:
> On 29 July 2015 at 22:42, Anita Kuno <anteaya at anteaya.info> wrote:
> 
>> On 07/29/2015 02:37 PM, Armando M. wrote:
>>> Hi,
>>>
>>> Since I was quoted, I would like to take the blame on behalf on the
>> Neutron
>>> core reviewer/drivers team for not providing the right guidance to
>> resolve
>>> the apparent conflict between the two proposals.
>>>
>>> As some reviewers mentioned, we should really strive to catch two birds
>>> with one stone, and ensure that, if at all possible, the same API can
>>> address both use cases presented. In this case, it sounds to me that the
>>> API proposed by the networking-sfc sub-project is more comprehensive, it
>>> has taken the steps to evolve independently from the Neutron core
>> platform,
>>> and it has been iterated on multiple times. Surely we can spin off (the
>>> forwarding engine) from the spin off (the SFC API), but that would feel
>>> like an overkill, especially when both have very little code to show for
>>> (and everyone knows that code wins in OpenStack).
>>>
>>> We should have provided Yuji Azama feedback a lot earlier in the process
>>> but we didn't. Again, blame me!
>>>
>>> I think that Sean raised a flag which should be seen as an acknowledgment
>>> of a need to reconcile the two efforts; let's move past the blame game
>> and
>>> the language barriers, and let's figure out how to address Yuji's need
>>> within the context of a single effort, without dismissing it. For this
>>> reason I am going to suggest we iterate within the networking-sfc
>> project,
>>> and block change 186663 <https://review.openstack.org/#/c/186663/>.
>> Let's
>>> figure out how the model/API has to evolve to accommodate the proposed
>> used
>>> need.
>>>
>>> If you disagree, please raise your concern on the patch in review itself.
>>>
>>> Cheers,
>>> Armando
>>
>> Hi Armando,
>>
>> If my attempts to offer some feedback on communication came across as
>> blame than I failed in what I was trying to accomplish.
> 
> 
>> My goal was and is to try to illustrate the point that competition and
>> collaboration are two separate directions.
>>
>> While some folks come from a competitive background, I hold the vision
>> of OpenStack as a collaborative experience. Some folks many need more
>> time than others to understand and digest the differences in behaviour
>> associated with the two styles of operating.
>>
>> I appreciate your email, Armando. At the very least it sets a good
>> example for others who many be new to collaboration to follow.
>>
>> As always, it is a pleasure to work with you Armax,
>> Anita.
> 
> 
> My point was simply to encourage the people involved in both efforts to
> take action after the discussion. The resolution of using one API over the
> other did not translate into a patch in any of our repos to capture the
> conclusion, at least not until now anyway, and without that, any
> back-and-forth is moot.
> 
> That said, I think it's important that you keep us honest along our journey
> :)
> 
> Thank you!

Thanks Armando,
Anita.

> 
> 
>>
>>>
>>> On 28 July 2015 at 15:01, Sean M. Collins <sean at coreitpro.com> wrote:
>>>
>>>> All,
>>>>
>>>> My suggestion was as follows:
>>>>
>>>>> <sc68cal> I'd say maybe an e-mail to the ML, with the results of this
>>>> meeting, and say that we want to try and converge where
>>>>> there is commonality
>>>>
>>>> I think there is overlap between the two APIs. Let's keep collaborating
>>>> on both the networking-sfc and packet forwarding APIs, to see where we
>>>> have commonality. I think Cathy's initial e-mail may have ruffled
>>>> feathers - and I'd like to smooth them out again. I think the statement
>>>> "we only need one API" is far too premature.
>>>>
>>>> Let's play nice with the other API proposals, yes?
>>>>
>>>>
>>>> --
>>>> Sean M. Collins
>>>>
>>>>
>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>>
>>>
>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>