On 02/05/15 12:02 -0700, Morgan Fainberg wrote:
On May 2, 2015, at 10:28, Monty Taylor <mord...@inaugust.com> wrote: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
Just to be super clear, I don't care either. :)
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.
ok, I'll bite. We didn't pick Falcon because Kurt was Marconi's PTL and Falcon's maintainer. The main reason it was picked was related to performance first[0] and time (We didn't/don't have enough resources to even think of porting the API) and at this point, I believe it's not even going to be considered anymore in the short future. There were lots of discussions around this, there were POCs and team work. I think it's fair to say that the team didn't blindly *ignored* what was recommended as the community framework but it picked what worked best for the service. [0] https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation
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 zaqarTo me this is a strong indicator that pecan will see more eyes and possibly be more open to improvement to meet the general need.
+1
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.+1
Please, lets not go back down this road, not yet at least. :)
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.
+1, go with Pecan if your requirements are not like Zaqar's. Contribute to Pecan and make it better. Flavio -- @flaper87 Flavio Percoco
pgp7Mf9zCWPWn.pgp
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev