Open Stack

On Monday, May 4, 2015, Flavio Percoco <flavio at redhat.com> wrote:

> 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.


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150507/ffb9e811/attachment.html>