Open Stack

On Tue, 21 Jun 2016, Sean Dague wrote:

> I honestly don't think raw WSGI is a bad choice here. People are going
> to be pretty familiar with it in related projects at this level.

Yeah, WSGI itself is a framework, one that is clearly defined and works
well for the types of things we are currently trying to do in HTTP
because for the most part what we are doing is really really really
simple and ought to require vanishingly small amounts of code.

> Using selector instead of Routes makes things different for unclear
> gain. Sticking with Routes seems more prudent.

I'm not willing to fight about it, but I really think Routes has
very bad taste when it comes to both WSGI and Python, probably at
least in part because of its inspiration in Rails.

Selector is WSGI middleware that does routing and dispatch to other
WSGI middleware or apps using easy to read and _explicit_ code that
is Pythonic.

     class MySelectorDispatchingWSGIApp(object):

         def __init__(self):
             self._selector = Selector()
             self._selector.add('/somethings/{id},
                                GET=handler.get_something,
                                PUT=handler.change_something)

         def __call__(self, environ, start_response):
             return self._selector(environ, start_response)

But okay, fine, if people think that's too scary and that change is
bad we can use something else.

> Doing Flask is fine, but do it because we think that's the way things
> should be done, not because it's a common in our community, which it
> clearly is not. The common pattern is custom WSGI + Routes / Paste (at
> least at this layer in the stack).

Because something is a common pattern that doesn't make it correct
or good. Many of the conversations about evoluting OpenStack in the
large and at the detail level seem to forget this. "That's the way
we've always done it" is painfully conservative and regressive and
witnessing people saying it (again and again) is depressing and
demotivating and says terrible things about the future of OpenStack.
Obviously we shouldn't be willy nilly causing change and churn in
existing code without good reason, but in new stuff, exploring the
options is not just good for the health and correctness of the
services it is also good for the health of the community.

But, as I've said elsewhere, what I want most is consensus. I'd prefer
a consensus to do something well instead of one to do something in a
mediocre fashion. I hope getting to at least good is why these
discussions are continuing.

What I would like from the placement code that will eventually
result from this is:

* code that operates with minimal configuration and has zero knobs
   exposed to deployers that shouldn't be turned (therefore no
   paste.ini[1])

* code that is simple to read, avoids excessive indirection and
   subclassing, and has clearly illuminated flows of control (minimal
   magic, minimal action at a distance, WSGI apps as functions not
   classes)

* code that, by virtue of both of the above and being created using
   TDD, is easy to test

To _me_, and strong opinions will differ, this especially discounts
using the pre-existing Nova WSGI model. It somewhat discounts using Flask
because of the globals (g etc) that proxy to request and app level
information but at least Flask is a common popular thing, so it has
that going for it.

You're right, Sean, when you say elsewhere in this thread that the
amount of "framework" stuff in my existing code is pretty minimal.
That's because the API is simple. The code should reflect that, it
does that by just being WSGI stuff.

[1] The current code does use paste.ini because that was the fastest
way to get working code running in the existing nova test environment
but a variety of people have said we should get rid of it and I
agree. Getting working code running is what has allowed this
conversation to happen and despite the meandering I think it is
worthwhile.

-- 
Chris Dent               (╯°□°)╯︵┻━┻            http://anticdent.org/
freenode: cdent                                         tw: @anticdent