Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Gregory Haynes]

On Wed, Jun 22, 2016, at 09:07 AM, Chris Dent wrote:
> On Tue, 21 Jun 2016, Sylvain Bauza wrote:
> 
> > To be honest, Chris and you were saying that you don't like Flask, and I'm 
> > a 
> > bit agreeing with you. Why now it's a good possibility ?
> 
> As I said when I started the other version of this same thread: What is
> most important to me is generating a consensus that we can actually
> commit to. To build a _real_ consensus it is important to have
> strong opionions that are weakly held[1] otherwise we are not
> actually evaluating the options.
> 
> You are right: I don't like Flask. It claims to be a microframework
> but to me it is overweight. I do, however, like it more than the
> chaos that is the current Nova WSGI stack.

This seems to be a recurring complaint in this thread - has any
consideration been given to using werkzeug[1] directly (its the library
underneath Flask). IMO this isn't a big win because the extra stuff that
comes in with Flask shouldn't present additional problems for us, but if
that really is the sticking point then it might be worth a look.

> 
> Flask has a very strong community and it does lots of stuff well
> such that we, in OpenStack, could just stop worrying about it. That
> is one reasonable way to approach doing WSGI moving forward.
> 

++. If there are issues we hit in Flask because of the extra components
we are so worried about then maybe we could work with them to resolve
these issues? I get the impression we are throwing out the baby with the
bathwater avoiding it altogether due to this fear.

> > Why not Routes and Paste couldn't be using also ?
> 
> More on this elsewhere in the thread.
> 

Cheers,
Greg

1: https://github.com/pallets/werkzeug

__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Sean M. Collins]

Sean Dague wrote:
> If we look at the iaas base layer:
> 
> Keystone - custom WSGI with Routes / Paste
> Glance - WSME + Routes / Paste
> Cinder - custom WSGI with Routes / Paste
> Neutron - pecan + Routes / Paste
> Nova - custom WSGI with Routes / Paste

Neutron's pecan code is still fairly new. Deployments still use the old
code[1]. So, I don't know if Neutron is quite there yet on the pecan
front. :(
 
[1]: 
https://github.com/openstack/neutron/blob/b59bb0fcfa41963c0e2f7bcbf34b7e4f4ff5cd08/neutron/common/config.py#L174

-- 
Sean M. Collins

__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Alex Xu]

2016-06-22 22:52 GMT+08:00 Chris Dent :

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

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.


>
> [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
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Chris Dent]

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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Sean Dague]

On 06/21/2016 10:10 AM, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2016-06-21 08:00:50 -0400:
>> On 06/21/2016 07:39 AM, Jay Pipes wrote:
>>> On 06/21/2016 05:43 AM, Sylvain Bauza wrote:
 Le 21/06/2016 10:04, Chris Dent a écrit :
> On Mon, 20 Jun 2016, Jay Pipes wrote:
>
>> Flask seems to be the most widely used and known WSGI framework so
>> for consistency's sake, I'm recommending we just use it and not rock
>> this boat. There are more important things to get hung up on than
>> this battle right now.
>
> That seems perfectly reasonable. My main goal in starting the
> discussion was to ensure that we reach some kind of consensus,
> whatever it might be[1]. It won't be too much of an ordeal to
> turn the existing pure WSGI stuff into Flask stuff.
>
> From my standpoint doing the initial development in straight WSGI
> was a win as it allowed for a lot of clarity from the inside out.
> Now that that development has shown the shape of the API we can
> do what we need to do to make it clear from outside in.
>
> Next question: There's some support for not using Paste and
> paste.ini. Is anyone opposed to that?
>

 Given Flask is not something we support yet in Nova, could we discuss on
 that during either a Nova meeting, or maybe wait for the midcycle ?
>>>
>>> I really don't want to wait for the mid-cycle. Happy to discuss in the
>>> Nova meeting, but my preference is to have Chris just modify his patch
>>> series to use Flask now and review it.
>>>
 To be honest, Chris and you were saying that you don't like Flask, and
 I'm a bit agreeing with you. Why now it's a good possibility ?
>>>
>>> Because Doug persuaded me that the benefits of being consistent with
>>> what the community is using outweigh my (and Chris') personal misgivings
>>> about the particular framework.
>>
>> Just to be clear
>>
>> http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==
>>
>> Flask is used by 2 (relatively new) projects in OpenStack
>>
>> If we look at the iaas base layer:
>>
>> Keystone - custom WSGI with Routes / Paste
>> Glance - WSME + Routes / Paste
>> Cinder - custom WSGI with Routes / Paste
>> Neutron - pecan + Routes / Paste
>> Nova - custom WSGI with Routes / Paste
>>
> 
> When I see "custom WSGI" I have a few thoughts:
> 
> * custom == special snowflake. But REST API's aren't exactly novel.
> 
> * If using a framework means not writing or cargo culting any custom
> WSGI code, that seems like a win for maintainability from the get go.
> 
> * If using a framework means handling errors more consistently, that
> seems like a win for operators.
> 
> * I don't have a grasp on how much custom WSGI code is actually
> involved. That would help us all evaluate the meaning of the statements
> above (both yours, and mine).

And my point is, it's not actually much. Because you still have to do
paste, and you still have to do request validation, and you still have
to actually right controllers and views. Routes has a restful resource
model -
https://routes.readthedocs.io/en/latest/restful.html#restful-services -
which is really not more complicated than the router decorators you get
with other services.

The places that we have large complicated wsgi flows is because we
supported extensions that can modify requests/responses, or the whole
XML/JSON content switching (which was a nightmare). All of these things
are being deleted.

If you actually look at the Nova patches that Chris is building, the
logic that's the wsgi "framework" is quite small and the application
logic is pretty much what it is going to be in any framework -
https://review.openstack.org/#/c/329152/11/nova/api/openstack/placement/handlers/inventory.py

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Sean Dague]

On 06/21/2016 10:11 AM, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2016-06-21 09:10:00 -0400:
>> The amount of wsgi glue above Routes / Paste is pretty minimal (after
>> you get rid of all the extensions facilities).
>>
>> Templating and Session handling are things we don't need. We're not a
>> webapp, we're a REST service. Saying that using a web app framework is
>> better than a little bit of wsgi glue seems weird to me.
>>
> 
> Actually we do have sessions. We just call them "tokens".

But that's not traditional sessions that use cookies and keep some
persistent state over the course of the session (besides auth). Which is
the kind of session support that these frameworks tend to provide.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Michael Krotscheck]

[Non-specific to nova]

I generated a list of which frameworks were in use in Mitaka - it's at the
top of the blog post I reference below, so you don't have to dig into it
too much to get the data.

TL/DR:
- falcon: 4 projects
- custom + routes: 12 projects
- pecan: 12 projects
- flask: 2 projects
- web.py: 1 project

With that in mind, I caution everyone not to surrender to the bandwagon
logical fallacy. "That's what we've always done" or "That's what most
people are doing" isn't actually an argument pro or con, it's merely
supporting the status quo because doing anything else would be hard (tm).

I think we can all agree on the following:
- Consistency is good. We need to pick one approach.
- Offloading support overhead onto a common codebase is better.

As for what the choice should be, this should be a thing the Architecture
WG makes a recommendation on, and with endorsement from the TC, would
actually be worthwhile for other projects to migrate to.

https://krotscheck.net/2016/03/25/we-need-an-consistent-openstack.html

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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Clint Byrum]

Excerpts from Sean Dague's message of 2016-06-21 08:00:50 -0400:
> On 06/21/2016 07:39 AM, Jay Pipes wrote:
> > On 06/21/2016 05:43 AM, Sylvain Bauza wrote:
> >> Le 21/06/2016 10:04, Chris Dent a écrit :
> >>> On Mon, 20 Jun 2016, Jay Pipes wrote:
> >>>
>  Flask seems to be the most widely used and known WSGI framework so
>  for consistency's sake, I'm recommending we just use it and not rock
>  this boat. There are more important things to get hung up on than
>  this battle right now.
> >>>
> >>> That seems perfectly reasonable. My main goal in starting the
> >>> discussion was to ensure that we reach some kind of consensus,
> >>> whatever it might be[1]. It won't be too much of an ordeal to
> >>> turn the existing pure WSGI stuff into Flask stuff.
> >>>
> >>> From my standpoint doing the initial development in straight WSGI
> >>> was a win as it allowed for a lot of clarity from the inside out.
> >>> Now that that development has shown the shape of the API we can
> >>> do what we need to do to make it clear from outside in.
> >>>
> >>> Next question: There's some support for not using Paste and
> >>> paste.ini. Is anyone opposed to that?
> >>>
> >>
> >> Given Flask is not something we support yet in Nova, could we discuss on
> >> that during either a Nova meeting, or maybe wait for the midcycle ?
> > 
> > I really don't want to wait for the mid-cycle. Happy to discuss in the
> > Nova meeting, but my preference is to have Chris just modify his patch
> > series to use Flask now and review it.
> > 
> >> To be honest, Chris and you were saying that you don't like Flask, and
> >> I'm a bit agreeing with you. Why now it's a good possibility ?
> > 
> > Because Doug persuaded me that the benefits of being consistent with
> > what the community is using outweigh my (and Chris') personal misgivings
> > about the particular framework.
> 
> Just to be clear
> 
> http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==
> 
> Flask is used by 2 (relatively new) projects in OpenStack
> 
> If we look at the iaas base layer:
> 
> Keystone - custom WSGI with Routes / Paste
> Glance - WSME + Routes / Paste
> Cinder - custom WSGI with Routes / Paste
> Neutron - pecan + Routes / Paste
> Nova - custom WSGI with Routes / Paste
> 

When I see "custom WSGI" I have a few thoughts:

* custom == special snowflake. But REST API's aren't exactly novel.

* If using a framework means not writing or cargo culting any custom
WSGI code, that seems like a win for maintainability from the get go.

* If using a framework means handling errors more consistently, that
seems like a win for operators.

* I don't have a grasp on how much custom WSGI code is actually
involved. That would help us all evaluate the meaning of the statements
above (both yours, and mine).

__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Clint Byrum]

Excerpts from Sean Dague's message of 2016-06-21 09:10:00 -0400:
> The amount of wsgi glue above Routes / Paste is pretty minimal (after
> you get rid of all the extensions facilities).
> 
> Templating and Session handling are things we don't need. We're not a
> webapp, we're a REST service. Saying that using a web app framework is
> better than a little bit of wsgi glue seems weird to me.
> 

Actually we do have sessions. We just call them "tokens".

__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[David Stanek]

On Tue, Jun 21, 2016 at 08:00:50AM -0400, Sean Dague wrote:
> 
> Keystone - custom WSGI with Routes / Paste
>

Keystone is moving toward Flask. I have an experimental patch that
moves us in that direction. I'm in the process to rebasing and
fixing it up since it's wildly out of date.

-- David

__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Hayes, Graham]

On 21/06/2016 13:04, Sean Dague wrote:
> On 06/21/2016 07:39 AM, Jay Pipes wrote:
>> On 06/21/2016 05:43 AM, Sylvain Bauza wrote:
>>> Le 21/06/2016 10:04, Chris Dent a écrit :
 On Mon, 20 Jun 2016, Jay Pipes wrote:

> Flask seems to be the most widely used and known WSGI framework so
> for consistency's sake, I'm recommending we just use it and not rock
> this boat. There are more important things to get hung up on than
> this battle right now.

 That seems perfectly reasonable. My main goal in starting the
 discussion was to ensure that we reach some kind of consensus,
 whatever it might be[1]. It won't be too much of an ordeal to
 turn the existing pure WSGI stuff into Flask stuff.

 From my standpoint doing the initial development in straight WSGI
 was a win as it allowed for a lot of clarity from the inside out.
 Now that that development has shown the shape of the API we can
 do what we need to do to make it clear from outside in.

 Next question: There's some support for not using Paste and
 paste.ini. Is anyone opposed to that?

>>>
>>> Given Flask is not something we support yet in Nova, could we discuss on
>>> that during either a Nova meeting, or maybe wait for the midcycle ?
>>
>> I really don't want to wait for the mid-cycle. Happy to discuss in the
>> Nova meeting, but my preference is to have Chris just modify his patch
>> series to use Flask now and review it.
>>
>>> To be honest, Chris and you were saying that you don't like Flask, and
>>> I'm a bit agreeing with you. Why now it's a good possibility ?
>>
>> Because Doug persuaded me that the benefits of being consistent with
>> what the community is using outweigh my (and Chris') personal misgivings
>> about the particular framework.
>
> Just to be clear
>
> http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==
>
> Flask is used by 2 (relatively new) projects in OpenStack

http://codesearch.openstack.org/?q=Flask=nope=requirements.txt=

Flask is used by a few projects.

>
> If we look at the iaas base layer:
>
> Keystone - custom WSGI with Routes / Paste
> Glance - WSME + Routes / Paste
> Cinder - custom WSGI with Routes / Paste
> Neutron - pecan + Routes / Paste
> Nova - custom WSGI with Routes / Paste
>
> 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.
>
> Using selector instead of Routes makes things different for unclear
> gain. Sticking with Routes seems more prudent.
>
> 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).
>
>   -Sean
>


__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Sean Dague]

On 06/21/2016 08:42 AM, Doug Hellmann wrote:
> Excerpts from Sean Dague's message of 2016-06-21 08:00:50 -0400:
>> On 06/21/2016 07:39 AM, Jay Pipes wrote:
>>> On 06/21/2016 05:43 AM, Sylvain Bauza wrote:
 Le 21/06/2016 10:04, Chris Dent a écrit :
> On Mon, 20 Jun 2016, Jay Pipes wrote:
>
>> Flask seems to be the most widely used and known WSGI framework so
>> for consistency's sake, I'm recommending we just use it and not rock
>> this boat. There are more important things to get hung up on than
>> this battle right now.
>
> That seems perfectly reasonable. My main goal in starting the
> discussion was to ensure that we reach some kind of consensus,
> whatever it might be[1]. It won't be too much of an ordeal to
> turn the existing pure WSGI stuff into Flask stuff.
>
> From my standpoint doing the initial development in straight WSGI
> was a win as it allowed for a lot of clarity from the inside out.
> Now that that development has shown the shape of the API we can
> do what we need to do to make it clear from outside in.
>
> Next question: There's some support for not using Paste and
> paste.ini. Is anyone opposed to that?
>

 Given Flask is not something we support yet in Nova, could we discuss on
 that during either a Nova meeting, or maybe wait for the midcycle ?
>>>
>>> I really don't want to wait for the mid-cycle. Happy to discuss in the
>>> Nova meeting, but my preference is to have Chris just modify his patch
>>> series to use Flask now and review it.
>>>
 To be honest, Chris and you were saying that you don't like Flask, and
 I'm a bit agreeing with you. Why now it's a good possibility ?
>>>
>>> Because Doug persuaded me that the benefits of being consistent with
>>> what the community is using outweigh my (and Chris') personal misgivings
>>> about the particular framework.
>>
>> Just to be clear
>>
>> http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==
>>
>> Flask is used by 2 (relatively new) projects in OpenStack
>>
>> If we look at the iaas base layer:
>>
>> Keystone - custom WSGI with Routes / Paste
>> Glance - WSME + Routes / Paste
>> Cinder - custom WSGI with Routes / Paste
>> Neutron - pecan + Routes / Paste
>> Nova - custom WSGI with Routes / Paste
>>
>> 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.
>>
>> Using selector instead of Routes makes things different for unclear
>> gain. Sticking with Routes seems more prudent.
>>
>> 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).
>>
>> -Sean
>>
> 
> As I told Jay, I don't care which specific framework is used. I
> care about the fact that while we're trying to get other projects
> to standardize on frameworks supported upstream so we have tools
> with good documentation and we carry less code directly in this
> community, we have consistently had a hard time convincing the nova
> team to choose one instead of building one.
> 
> Jay didn't like the object-dispatch model used in Pecan, so I pointed
> out that Flask is also in use elsewhere. The fact that Flask is not yet
> widespread indicates that project teams are not needlessly rewriting
> existing API services, rather than lack of acceptance. If you don't like
> either Flaks or Pecan, look at Pyramid or Pylons or one of the others.
> But please stop building new frameworks that make your project so
> completely different from everything else in the Python ecosystem.

The amount of wsgi glue above Routes / Paste is pretty minimal (after
you get rid of all the extensions facilities).

Templating and Session handling are things we don't need. We're not a
webapp, we're a REST service. Saying that using a web app framework is
better than a little bit of wsgi glue seems weird to me.

Falcon looks like the only thing out there which is really stripped down
to this little bit of glue layer. So if the answer is "must use
framework" that seems like the right answer. However, Routes + Paste is
really the framework we are using broadly in OpenStack. And a lot of the
common middleware assume that.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Doug Hellmann]

Excerpts from Sean Dague's message of 2016-06-21 08:00:50 -0400:
> On 06/21/2016 07:39 AM, Jay Pipes wrote:
> > On 06/21/2016 05:43 AM, Sylvain Bauza wrote:
> >> Le 21/06/2016 10:04, Chris Dent a écrit :
> >>> On Mon, 20 Jun 2016, Jay Pipes wrote:
> >>>
>  Flask seems to be the most widely used and known WSGI framework so
>  for consistency's sake, I'm recommending we just use it and not rock
>  this boat. There are more important things to get hung up on than
>  this battle right now.
> >>>
> >>> That seems perfectly reasonable. My main goal in starting the
> >>> discussion was to ensure that we reach some kind of consensus,
> >>> whatever it might be[1]. It won't be too much of an ordeal to
> >>> turn the existing pure WSGI stuff into Flask stuff.
> >>>
> >>> From my standpoint doing the initial development in straight WSGI
> >>> was a win as it allowed for a lot of clarity from the inside out.
> >>> Now that that development has shown the shape of the API we can
> >>> do what we need to do to make it clear from outside in.
> >>>
> >>> Next question: There's some support for not using Paste and
> >>> paste.ini. Is anyone opposed to that?
> >>>
> >>
> >> Given Flask is not something we support yet in Nova, could we discuss on
> >> that during either a Nova meeting, or maybe wait for the midcycle ?
> > 
> > I really don't want to wait for the mid-cycle. Happy to discuss in the
> > Nova meeting, but my preference is to have Chris just modify his patch
> > series to use Flask now and review it.
> > 
> >> To be honest, Chris and you were saying that you don't like Flask, and
> >> I'm a bit agreeing with you. Why now it's a good possibility ?
> > 
> > Because Doug persuaded me that the benefits of being consistent with
> > what the community is using outweigh my (and Chris') personal misgivings
> > about the particular framework.
> 
> Just to be clear
> 
> http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==
> 
> Flask is used by 2 (relatively new) projects in OpenStack
> 
> If we look at the iaas base layer:
> 
> Keystone - custom WSGI with Routes / Paste
> Glance - WSME + Routes / Paste
> Cinder - custom WSGI with Routes / Paste
> Neutron - pecan + Routes / Paste
> Nova - custom WSGI with Routes / Paste
> 
> 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.
> 
> Using selector instead of Routes makes things different for unclear
> gain. Sticking with Routes seems more prudent.
> 
> 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).
> 
> -Sean
> 

As I told Jay, I don't care which specific framework is used. I
care about the fact that while we're trying to get other projects
to standardize on frameworks supported upstream so we have tools
with good documentation and we carry less code directly in this
community, we have consistently had a hard time convincing the nova
team to choose one instead of building one.

Jay didn't like the object-dispatch model used in Pecan, so I pointed
out that Flask is also in use elsewhere. The fact that Flask is not yet
widespread indicates that project teams are not needlessly rewriting
existing API services, rather than lack of acceptance. If you don't like
either Flaks or Pecan, look at Pyramid or Pylons or one of the others.
But please stop building new frameworks that make your project so
completely different from everything else in the Python ecosystem.

Doug

__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Sylvain Bauza]

Le 21/06/2016 14:00, Sean Dague a écrit :

On 06/21/2016 07:39 AM, Jay Pipes wrote:

On 06/21/2016 05:43 AM, Sylvain Bauza wrote:

Le 21/06/2016 10:04, Chris Dent a écrit :

On Mon, 20 Jun 2016, Jay Pipes wrote:


Flask seems to be the most widely used and known WSGI framework so
for consistency's sake, I'm recommending we just use it and not rock
this boat. There are more important things to get hung up on than
this battle right now.

That seems perfectly reasonable. My main goal in starting the
discussion was to ensure that we reach some kind of consensus,
whatever it might be[1]. It won't be too much of an ordeal to
turn the existing pure WSGI stuff into Flask stuff.

 From my standpoint doing the initial development in straight WSGI
was a win as it allowed for a lot of clarity from the inside out.
Now that that development has shown the shape of the API we can
do what we need to do to make it clear from outside in.

Next question: There's some support for not using Paste and
paste.ini. Is anyone opposed to that?


Given Flask is not something we support yet in Nova, could we discuss on
that during either a Nova meeting, or maybe wait for the midcycle ?

I really don't want to wait for the mid-cycle. Happy to discuss in the
Nova meeting, but my preference is to have Chris just modify his patch
series to use Flask now and review it.


To be honest, Chris and you were saying that you don't like Flask, and
I'm a bit agreeing with you. Why now it's a good possibility ?

Because Doug persuaded me that the benefits of being consistent with
what the community is using outweigh my (and Chris') personal misgivings
about the particular framework.

Just to be clear

http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==

Flask is used by 2 (relatively new) projects in OpenStack


TBC, even Blazar (ex. Climate reservation system) no longer uses Flask 
for its API v2 (Pecan+WSME), just for the legacy v1.




If we look at the iaas base layer:

Keystone - custom WSGI with Routes / Paste
Glance - WSME + Routes / Paste
Cinder - custom WSGI with Routes / Paste
Neutron - pecan + Routes / Paste
Nova - custom WSGI with Routes / Paste

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.

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


I tend to agree with you here. Also, tbc, the placement API is still in 
the Nova tree so that's why I wonder why we should have a different WSGI 
router.




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


++


-Sean




__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Sean Dague]

On 06/21/2016 07:39 AM, Jay Pipes wrote:
> On 06/21/2016 05:43 AM, Sylvain Bauza wrote:
>> Le 21/06/2016 10:04, Chris Dent a écrit :
>>> On Mon, 20 Jun 2016, Jay Pipes wrote:
>>>
 Flask seems to be the most widely used and known WSGI framework so
 for consistency's sake, I'm recommending we just use it and not rock
 this boat. There are more important things to get hung up on than
 this battle right now.
>>>
>>> That seems perfectly reasonable. My main goal in starting the
>>> discussion was to ensure that we reach some kind of consensus,
>>> whatever it might be[1]. It won't be too much of an ordeal to
>>> turn the existing pure WSGI stuff into Flask stuff.
>>>
>>> From my standpoint doing the initial development in straight WSGI
>>> was a win as it allowed for a lot of clarity from the inside out.
>>> Now that that development has shown the shape of the API we can
>>> do what we need to do to make it clear from outside in.
>>>
>>> Next question: There's some support for not using Paste and
>>> paste.ini. Is anyone opposed to that?
>>>
>>
>> Given Flask is not something we support yet in Nova, could we discuss on
>> that during either a Nova meeting, or maybe wait for the midcycle ?
> 
> I really don't want to wait for the mid-cycle. Happy to discuss in the
> Nova meeting, but my preference is to have Chris just modify his patch
> series to use Flask now and review it.
> 
>> To be honest, Chris and you were saying that you don't like Flask, and
>> I'm a bit agreeing with you. Why now it's a good possibility ?
> 
> Because Doug persuaded me that the benefits of being consistent with
> what the community is using outweigh my (and Chris') personal misgivings
> about the particular framework.

Just to be clear

http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==

Flask is used by 2 (relatively new) projects in OpenStack

If we look at the iaas base layer:

Keystone - custom WSGI with Routes / Paste
Glance - WSME + Routes / Paste
Cinder - custom WSGI with Routes / Paste
Neutron - pecan + Routes / Paste
Nova - custom WSGI with Routes / Paste

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.

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

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

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Jay Pipes]

On 06/21/2016 05:43 AM, Sylvain Bauza wrote:

Le 21/06/2016 10:04, Chris Dent a écrit :

On Mon, 20 Jun 2016, Jay Pipes wrote:


Flask seems to be the most widely used and known WSGI framework so
for consistency's sake, I'm recommending we just use it and not rock
this boat. There are more important things to get hung up on than
this battle right now.


That seems perfectly reasonable. My main goal in starting the
discussion was to ensure that we reach some kind of consensus,
whatever it might be[1]. It won't be too much of an ordeal to
turn the existing pure WSGI stuff into Flask stuff.

From my standpoint doing the initial development in straight WSGI
was a win as it allowed for a lot of clarity from the inside out.
Now that that development has shown the shape of the API we can
do what we need to do to make it clear from outside in.

Next question: There's some support for not using Paste and
paste.ini. Is anyone opposed to that?



Given Flask is not something we support yet in Nova, could we discuss on
that during either a Nova meeting, or maybe wait for the midcycle ?


I really don't want to wait for the mid-cycle. Happy to discuss in the 
Nova meeting, but my preference is to have Chris just modify his patch 
series to use Flask now and review it.



To be honest, Chris and you were saying that you don't like Flask, and
I'm a bit agreeing with you. Why now it's a good possibility ?


Because Doug persuaded me that the benefits of being consistent with 
what the community is using outweigh my (and Chris') personal misgivings 
about the particular framework.



Why not Routes and Paste couldn't be using also ?


It's about using a code style and library that is in use by other 
projects so that new contributors can have some consistency in the WSGI 
handling code.


Best,
-jay


See, it's a very important question, and I remember that discussing on
Nova API v3 2 years ago was also having these kinds of discussion.

-Sylvain



[1] As long as it wasn't the overly complex Nova way.

Or WSME!



__
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




__
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



__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Sylvain Bauza]

Le 21/06/2016 10:04, Chris Dent a écrit :

On Mon, 20 Jun 2016, Jay Pipes wrote:

Flask seems to be the most widely used and known WSGI framework so 
for consistency's sake, I'm recommending we just use it and not rock 
this boat. There are more important things to get hung up on than 
this battle right now.


That seems perfectly reasonable. My main goal in starting the
discussion was to ensure that we reach some kind of consensus,
whatever it might be[1]. It won't be too much of an ordeal to
turn the existing pure WSGI stuff into Flask stuff.

From my standpoint doing the initial development in straight WSGI
was a win as it allowed for a lot of clarity from the inside out.
Now that that development has shown the shape of the API we can
do what we need to do to make it clear from outside in.

Next question: There's some support for not using Paste and
paste.ini. Is anyone opposed to that?



Given Flask is not something we support yet in Nova, could we discuss on 
that during either a Nova meeting, or maybe wait for the midcycle ?


To be honest, Chris and you were saying that you don't like Flask, and 
I'm a bit agreeing with you. Why now it's a good possibility ?


Why not Routes and Paste couldn't be using also ?
See, it's a very important question, and I remember that discussing on 
Nova API v3 2 years ago was also having these kinds of discussion.


-Sylvain



[1] As long as it wasn't the overly complex Nova way.

Or WSME!



__
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


__
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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Chris Dent]

On Mon, 20 Jun 2016, Jay Pipes wrote:

Flask seems to be the most widely used and known WSGI framework so for 
consistency's sake, I'm recommending we just use it and not rock this boat. 
There are more important things to get hung up on than this battle right now.


That seems perfectly reasonable. My main goal in starting the
discussion was to ensure that we reach some kind of consensus,
whatever it might be[1]. It won't be too much of an ordeal to
turn the existing pure WSGI stuff into Flask stuff.


From my standpoint doing the initial development in straight WSGI

was a win as it allowed for a lot of clarity from the inside out.
Now that that development has shown the shape of the API we can
do what we need to do to make it clear from outside in.

Next question: There's some support for not using Paste and
paste.ini. Is anyone opposed to that?

[1] As long as it wasn't the overly complex Nova way.

Or WSME!

--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
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

[openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Jay Pipes]

Hi Chris, stackers,

OK, so I've been a pretty vocal proponent of Chris' approach to the new 
placement REST API endpoint, which is to use no WSGI frameworks and 
instead just use the selector library (or Routes as a second choice) for 
defining the URI mappings.


However, I had a chat with Doug (cc'd) today and he pulled me around to 
the view that it is better to use one of the WSGI frameworks used by the 
other OpenStack projects instead of going in a completely new direction. 
It will be easier for other OpenStack contributors to become familiar 
with the new placement API endpoint code if it uses Flask.


So, as much as I'm not a fan of any framework for handling WSGI stuff, 
Flask is probably the best choice for the new placement API code. I'd 
suggest Falcon but a) it's been a while since I used Falcon (lots of 
stuff has changed since I last worked with it) and b) it's only used by 
Zaqar and is better suited (IMO) for data plane APIs than control plane 
APIs.


Flask seems to be the most widely used and known WSGI framework so for 
consistency's sake, I'm recommending we just use it and not rock this 
boat. There are more important things to get hung up on than this battle 
right now.


Best,
-jay

__
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