Open Stack

> On May 2, 2015, at 10:28, Monty Taylor <mordred at 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
> 
> 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
> 

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. 

> 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

> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev