Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask
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 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
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: openstack-dev-requ...@li
Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask
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
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. 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. Why not Routes and Paste couldn't be using also ? More on this elsewhere in the thread. [1] For one of many references: http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinions.html -- 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
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&i=nope&files=&repos= >> >> 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
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
[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
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&i=nope&files=&repos= > > 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
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
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
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&i=nope&files=&repos= > > Flask is used by 2 (relatively new) projects in OpenStack http://codesearch.openstack.org/?q=Flask&i=nope&files=requirements.txt&repos= 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
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&i=nope&files=&repos= >> >> 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
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&i=nope&files=&repos= > > 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
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&i=nope&files=&repos= 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
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&i=nope&files=&repos= 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
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
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
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