On 12/03/2014 10:16 AM, Nikolay Markov wrote:
It would be great to look at some obvious points where Pecan is better
than Flask despite of the fact that it's used by the community. I
still don't see a single and I don't think the principle "jump from
the cliff if everyone does" works well in such cases.

This is part of why the Fuel development team is viewed as not working with the OpenStack community in many ways. The Fuel team is doing a remarkable job in changing previously-all-internal-to-Mirantis communication patterns to instead be on a transparent basis in the mailing lists and on IRC. I sincerely applaud the Fuel team for that.

However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. It's expected that when you have an OpenStack REST API project, that you try to use the tools that the shared community uses, builds, and supports. Otherwise, you aren't being a team player.

In the past, certain teams have chosen to use something other than Pecan due to technical reasons. For example, Zaqar's team chose to use the Falcon framework instead of the Pecan framework. Zaqar, like Swift, is a data API, not a control API, and raw performance is critical to the project's API endpoint). This is, incidentally, why the Swift team chose to use its swob framework over Webob (which Pecan uses).

However, the reason that these were chosen was definitely not "it doesn't support the coding patterns I like". There's something that comes from being a team player. And one of those things is "going with the flow" when there isn't a real technical reason not to. All of us can and do find things we don't like about *all* of the projects that we work on. The difference between team players and non-team players is that team players strongly weigh their decisions and opinions based on what the team is doing and how the team can improve.


OpenStack-dev mailing list

Reply via email to