Open Stack

On 19/03/14 11:00 -0400, Doug Hellmann wrote:
>
>
>
>On Wed, Mar 19, 2014 at 7:31 AM, Thierry Carrez <thierry at openstack.org> wrote:
>
>    Kurt Griffiths wrote:
>    > Kudos to Balaji for working so hard on this. I really appreciate his
>    candid feedback on both frameworks.
>
>    Indeed, that analysis is very much appreciated.
>
>    From the Technical Committee perspective, we put a high weight on a
>    factor that was not included in the report results: consistency and
>    convergence between projects we commonly release in an integrated manner
>    every 6 months. There was historically a lot of deviation, but as we add
>    more projects that deviation is becoming more costly. We want developers
>    to be able to jump from one project to another easily, and we want
>    convergence from an operators perspective. 
>
>
>    Individual projects are obviously allowed to pick the best tool in their
>    toolbox. But the TC may also decide to let projects live out of the
>    "integrated release" if we feel they would add too much divergence in.
>
>
>As Thierry points out, an important aspect of being in the integrated release
>is being aligned with the rest of the community. The evaluation gives
>"community" considerations the lowest weight among the criteria considered.
>Does that ranking reflect the opinion of the entire Marconi team? If so, what
>benefits do you see to being integrated?

Doug, I'm sure your intentions are good but lets try to avoid this
kind of questions. I don't think the Marconi team has shown any kind
of closed development since the project was kicked off. We've
worked hard to integrate with OpenStack's standards, the overall
community and with other projects as well. We've had sessions for
cross-project integrations, we've had discussions with other teams
that lead us to improve Marconi and ease our collaboration with the
whole community. Hard work has been put on integrating with our CI
system. The team has participated in upstream discussions. The team
has also strictly followed the upstream release cycle - even before
Marconi was incubated - and finally the team is here discussing pros
and cons of the framework that has been chosen. Not to mention the
discussions we had about Falcon and Pecan that you pointed out below.

The evaluation of Pecan vs Falcon is purely technical - none of us is
trying to hide that - the reason being that our choice of falcon was
purely technical. There has never been in our team a will of going
against the community and after these last months of hard work,
completely focused on the integration requirements, I think the team's
intentions should be more than clear.

Just a side note, I'm very proud of what the team has done so far and
how the community around Marconi has grown 'til now and I'm also proud
of the work the team has done to integrate with the OpenStack
community.

Back to the discussion, I understand the choice of using Falcon
instead of Pecan has an impact in the community that was not
considered in the evaluation and I'm very sorry for that. However,
lets remember that this evaluation was done by someone completely
*new* to the 3 communities (OpenStack's, Falcon's and Pecan's) because
it was meant to be purely technical and not biased.

In order to fulfill this requirement in the evaluation, folks from the
OpenStack community need to chime in - as we're doing now - and help
filling the pros and cons of having 1-fw-to-rule-openstack, a set of
frameworks or even better evaluate these needs in a case-by-case
basis.

Again, I may be wrong but I haven't seen the needs, pros and cons of
standardizing the libraries across projects written anywhere. I'm sure
there are pros and cons community-wise and I think this case of study
(Pecan and / or Falcon) will be useful for future cases like this one.

That said and considering that this matters to the whole community,
I'd like to invite folks to help us create a list of pros and cons
from having just 1 common library as opposed to having a limited set
of supported libraries being used across projects. Whatever comes out
from this discussion could be used as a base to evaluate future cases
like this and it'll obviously be integrated to the evaluation being
discussed.

If this was already discussed in emails, meetings and / or there's
something written somewhere, I'd really appreciate a link pointing to
such resource that could be used to complete the evaluation.

[snip]

>    > After reviewing the report below, I would recommend that Marconi
>    > continue using Falcon for the v1.1 API and then re-evaluate Pecan for
>    > v2.0 or possibly look at using swob.
>
>    The report (and your email below) makes a compelling argument that
>    Falcon is a better match for Marconi's needs (or for a data-plane API)
>    than Pecan currently is. My question would be, can Pecan be improved to
>    also cover Marconi's use case ? Could we have the best of both worlds
>    (an appropriate tool *and* convergence) ?
>
>
>We had several conversations with Kurt and Flavio in Hong Kong about adding
>features to Pecan to support the Marconi team, and Ryan prototyped some of
>those changes shortly after we returned home. Was any of that work considered
>in the evaluation?

There was a collaboration between Balaji and Ryan, AFAIK. I'm sure
they both can add more here than myself.

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140320/37bd21d3/attachment.pgp>