On 19/03/14 11:00 -0400, Doug Hellmann wrote:
On Wed, Mar 19, 2014 at 7:31 AM, Thierry Carrez <thie...@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 wantconvergence 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
pgpx7fnwuh8Bj.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev