Open Stack

On 05/01/2015 09:16 PM, Jamie Lennox wrote:
> Hi all, 
> 
> At around the time Barbican was applying for incubation there was a
> discussion about "supported" WSGI frameworks. From memory the decision
> at the time was that Pecan was to be the only supported framework and
> that for incubation Barbican had to convert to Pecan (from Falcon).
> 
> Keystone is looking to ditch our crusty old, home-grown wsgi layer for
> an external framework and both Pecan and Falcon are in global
> requirements. 
> 
> In the experimenting I've done Pecan provides a lot of stuff we don't
> need and some that just gets in the way. To call out a few:
>  * the rendering engine really doesn't make sense for us, for APIs, and
> where we are often returning different data (not just different views or
> data) based on Content-Type. 
>  * The security enforcement within Pecan does not really mesh with how
> we enforce policy, nor does the way we build controller objects per
> resource. It seems we will have to build this for ourselves on top of
> pecan
> 
> and there are just various other niggles. 
> 
> THIS IS NOT SUPPOSED TO START A DEBATE ON THE VIRTUES OF EACH FRAMEWORK.
> 
> Everything I've found can be dealt with and pecan will be a vast
> improvement over what we use now. I have also not written a POC with
> Falcon to know that it will suit any better.
> 
> My question is: Does the ruling that Pecan is the only WSGI framework
> for OpenStack stand? I don't want to have 100s of frameworks in the
> global requirements, but given falcon is already there iff a POC
> determines that Falcon is a better fit for keystone can we use it? 

a) Just to be clear - I don't actually care

That said:

falcon is a wsgi framework written by kgriffs who was PTL of marconi who
has since being involved with OpenStack. My main perception of it has
always been as a set of people annoyed by openstack doing their own
thing. That's fine - but I don't have much of a use for that myself.

pecan is a wsgi framework written by Dreamhost that eventually moved
itself into stackforge to better enable collaboration with our community
after we settled on it as the API for things moving forward.

Since the decision that new REST apis should be written in Pecan, the
following projects have adopted it:

openstack:
barbican
ceilometer
designate
gnocchi
ironic
ironic-python-agent
kite
magnum
storyboard
tuskar

stackforge:
anchor
blazar
cerberus
cloudkitty
cue
fuel-ostf
fuel-provision
graffiti
libra
magnetodb
monasca-api
mistral
octavia
poppy
radar
refstack
solum
storyboard
surveil
terracotta

On the other hand, the following use falcon:

stachtach-quincy
zaqar

That means that for all of the moaning and complaining, there is
essentially one thing that uses it - the project that was started by the
person who wrote it and has since quit.

I'm sure it's not perfect - but the code is in stackforge - I'm sure we
can improve it if there is something missing. OTOH - if we're going to
go back down this road, I'd think it would be more useful to maybe look
at flask or something else that has a large following in the python
community at large to try to reduce the amount of special we are.

But honestly - I think it matters almost not at all, which is why I keep
telling people to just use pecan ... basically, the argument is not
worth it.

Monty