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

Attachment: 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

Reply via email to