<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-06-22 22:52 GMT+08:00 Chris Dent <span dir="ltr"><<a href="mailto:cdent+os@anticdent.org" target="_blank">cdent+os@anticdent.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 21 Jun 2016, Sean Dague wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I honestly don't think raw WSGI is a bad choice here. People are going<br>
to be pretty familiar with it in related projects at this level.<br>
</blockquote>
<br></span>
Yeah, WSGI itself is a framework, one that is clearly defined and works<br>
well for the types of things we are currently trying to do in HTTP<br>
because for the most part what we are doing is really really really<br>
simple and ought to require vanishingly small amounts of code.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Using selector instead of Routes makes things different for unclear<br>
gain. Sticking with Routes seems more prudent.<br>
</blockquote>
<br></span>
I'm not willing to fight about it, but I really think Routes has<br>
very bad taste when it comes to both WSGI and Python, probably at<br>
least in part because of its inspiration in Rails.<br>
<br>
Selector is WSGI middleware that does routing and dispatch to other<br>
WSGI middleware or apps using easy to read and _explicit_ code that<br>
is Pythonic.<br>
<br>
class MySelectorDispatchingWSGIApp(object):<br>
<br>
def __init__(self):<br>
self._selector = Selector()<br>
self._selector.add('/somethings/{id},<br>
GET=handler.get_something,<br>
PUT=handler.change_something)<br>
<br>
def __call__(self, environ, start_response):<br>
return self._selector(environ, start_response)<br>
<br>
But okay, fine, if people think that's too scary and that change is<br>
bad we can use something else.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Doing Flask is fine, but do it because we think that's the way things<br>
should be done, not because it's a common in our community, which it<br>
clearly is not. The common pattern is custom WSGI + Routes / Paste (at<br>
least at this layer in the stack).<br>
</blockquote>
<br></span>
Because something is a common pattern that doesn't make it correct<br>
or good. Many of the conversations about evoluting OpenStack in the<br>
large and at the detail level seem to forget this. "That's the way<br>
we've always done it" is painfully conservative and regressive and<br>
witnessing people saying it (again and again) is depressing and<br>
demotivating and says terrible things about the future of OpenStack.<br>
Obviously we shouldn't be willy nilly causing change and churn in<br>
existing code without good reason, but in new stuff, exploring the<br>
options is not just good for the health and correctness of the<br>
services it is also good for the health of the community.<br>
<br>
But, as I've said elsewhere, what I want most is consensus. I'd prefer<br>
a consensus to do something well instead of one to do something in a<br>
mediocre fashion. I hope getting to at least good is why these<br>
discussions are continuing.<br>
<br>
What I would like from the placement code that will eventually<br>
result from this is:<br>
<br>
* code that operates with minimal configuration and has zero knobs<br>
exposed to deployers that shouldn't be turned (therefore no<br>
paste.ini[1])<br>
<br>
* code that is simple to read, avoids excessive indirection and<br>
subclassing, and has clearly illuminated flows of control (minimal<br>
magic, minimal action at a distance, WSGI apps as functions not<br>
classes)<br>
<br>
* code that, by virtue of both of the above and being created using<br>
TDD, is easy to test<br>
<br>
To _me_, and strong opinions will differ, this especially discounts<br>
using the pre-existing Nova WSGI model. It somewhat discounts using Flask<br>
because of the globals (g etc) that proxy to request and app level<br>
information but at least Flask is a common popular thing, so it has<br>
that going for it.<br>
<br>
You're right, Sean, when you say elsewhere in this thread that the<br>
amount of "framework" stuff in my existing code is pretty minimal.<br>
That's because the API is simple. The code should reflect that, it<br>
does that by just being WSGI stuff.<br></blockquote><div><br></div><div>I also agree with the WSGI framework actually is very simple and minimal. And look at the nova api code, I didn't remember we changed the code in past few releases. The complex thing is the framework for REST API App, the framework need to support microversion, input validation, even documentation. So i'm thinking whether easy to support microversion in Flask, does Flask provide input validation and documentation? If not, I didn't think Flask provide too much benefit to us than custom WSGI framework.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1] The current code does use paste.ini because that was the fastest<br>
way to get working code running in the existing nova test environment<br>
but a variety of people have said we should get rid of it and I<br>
agree. Getting working code running is what has allowed this<br>
conversation to happen and despite the meandering I think it is<br>
worthwhile.<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Chris Dent (╯°□°)╯︵┻━┻ <a href="http://anticdent.org/" rel="noreferrer" target="_blank">http://anticdent.org/</a><br>
freenode: cdent tw: @anticdent</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>