<br><br>On Monday, May 4, 2015, Flavio Percoco <<a href="mailto:flavio@redhat.com">flavio@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/05/15 12:02 -0700, Morgan Fainberg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On May 2, 2015, at 10:28, Monty Taylor <<a>mordred@inaugust.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/01/2015 09:16 PM, Jamie Lennox wrote:<br>
Hi all,<br>
<br>
At around the time Barbican was applying for incubation there was a<br>
discussion about "supported" WSGI frameworks. From memory the decision<br>
at the time was that Pecan was to be the only supported framework and<br>
that for incubation Barbican had to convert to Pecan (from Falcon).<br>
<br>
Keystone is looking to ditch our crusty old, home-grown wsgi layer for<br>
an external framework and both Pecan and Falcon are in global<br>
requirements.<br>
<br>
In the experimenting I've done Pecan provides a lot of stuff we don't<br>
need and some that just gets in the way. To call out a few:<br>
* the rendering engine really doesn't make sense for us, for APIs, and<br>
where we are often returning different data (not just different views or<br>
data) based on Content-Type.<br>
* The security enforcement within Pecan does not really mesh with how<br>
we enforce policy, nor does the way we build controller objects per<br>
resource. It seems we will have to build this for ourselves on top of<br>
pecan<br>
<br>
and there are just various other niggles.<br>
<br>
THIS IS NOT SUPPOSED TO START A DEBATE ON THE VIRTUES OF EACH FRAMEWORK.<br>
<br>
Everything I've found can be dealt with and pecan will be a vast<br>
improvement over what we use now. I have also not written a POC with<br>
Falcon to know that it will suit any better.<br>
<br>
My question is: Does the ruling that Pecan is the only WSGI framework<br>
for OpenStack stand? I don't want to have 100s of frameworks in the<br>
global requirements, but given falcon is already there iff a POC<br>
determines that Falcon is a better fit for keystone can we use it?<br>
</blockquote>
<br>
a) Just to be clear - I don't actually care<br>
</blockquote></blockquote>
<br>
Just to be super clear, I don't care either. :)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That said:<br>
<br>
falcon is a wsgi framework written by kgriffs who was PTL of marconi who<br>
has since being involved with OpenStack. My main perception of it has<br>
always been as a set of people annoyed by openstack doing their own<br>
thing. That's fine - but I don't have much of a use for that myself.<br>
</blockquote></blockquote>
<br>
ok, I'll bite.<br>
<br>
We didn't pick Falcon because Kurt was Marconi's PTL and Falcon's<br>
maintainer. The main reason it was picked was related to performance<br>
first[0] and time (We didn't/don't have enough resources to even think<br>
of porting the API) and at this point, I believe it's not even going<br>
to be considered anymore in the short future.</blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There were lots of discussions around this, there were POCs and team<br>
work. I think it's fair to say that the team didn't blindly *ignored*<br>
what was recommended as the community framework but it picked what<br>
worked best for the service.<br>
<br>
[0] <a href="https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation" target="_blank">https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
pecan is a wsgi framework written by Dreamhost that eventually moved<br>
itself into stackforge to better enable collaboration with our community<br>
after we settled on it as the API for things moving forward.<br>
<br>
Since the decision that new REST apis should be written in Pecan, the<br>
following projects have adopted it:<br>
<br>
openstack:<br>
barbican<br>
ceilometer<br>
designate<br>
gnocchi<br>
ironic<br>
ironic-python-agent<br>
kite<br>
magnum<br>
storyboard<br>
tuskar<br>
<br>
stackforge:<br>
anchor<br>
blazar<br>
cerberus<br>
cloudkitty<br>
cue<br>
fuel-ostf<br>
fuel-provision<br>
graffiti<br>
libra<br>
magnetodb<br>
monasca-api<br>
mistral<br>
octavia<br>
poppy<br>
radar<br>
refstack<br>
solum<br>
storyboard<br>
surveil<br>
terracotta<br>
<br>
On the other hand, the following use falcon:<br>
<br>
stachtach-quincy<br>
zaqar<br>
<br>
</blockquote>
<br>
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.<br>
</blockquote>
<br>
+1<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That means that for all of the moaning and complaining, there is<br>
essentially one thing that uses it - the project that was started by the<br>
person who wrote it and has since quit.<br>
<br>
I'm sure it's not perfect - but the code is in stackforge - I'm sure we<br>
can improve it if there is something missing. OTOH - if we're going to<br>
go back down this road, I'd think it would be more useful to maybe look<br>
at flask or something else that has a large following in the python<br>
community at large to try to reduce the amount of special we are.<br>
<br>
</blockquote>
<br>
+1<br>
</blockquote>
<br>
Please, lets not go back down this road, not yet at least. :)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But honestly - I think it matters almost not at all, which is why I keep<br>
telling people to just use pecan ... basically, the argument is not<br>
worth it.<br>
</blockquote></blockquote>
<br>
+1, go with Pecan if your requirements are not like Zaqar's.<br>
Contribute to Pecan and make it better.<br>
<br>
Flavio<br>
<br>
-- <br>
@flaper87<br>
Flavio Percoco<br>
</blockquote>