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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
