On Monday, May 4, 2015, Flavio Percoco <fla...@redhat.com> wrote: > 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.
I'm just going to pipe up and say that's a terribly shallow reason for choosing a web framework, and I think it's silly and embarrassing that there's not a stronger community preference for more mature frameworks. I take that as a sign that most of our developer community is coming from non-Python backgrounds, which is fine, but this whole conversation has always felt like a plague of Not-Invented-Here, which baffles me. > > 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 >>> zaqar >>> >>> >> To 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 >
__________________________________________________________________________ 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
