Open Stack

On 02/05/15 12:02 -0700, Morgan Fainberg wrote:
>
>
>> 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

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
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150504/6f2c5a6d/attachment.pgp>