[openstack-dev] [Fuel][Nailgun] Web framework

Fox, Kevin M Kevin.Fox at pnnl.gov
Wed Dec 3 17:07:44 UTC 2014

+1. Well said. I second the applauding of the Fuel's development team's for their changing of their communications patterns (that's never easy) and also the desire for closer integration with the rest of the OpenStack community.
From: Jay Pipes [jaypipes at gmail.com]
Sent: Wednesday, December 03, 2014 7:32 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Fuel][Nailgun] Web framework

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
OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list