settingsLogin | Registersettings

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

0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jun 21, 2016 in openstack-dev by Jay_Pipes (59,760 points)   3 11 14
retagged Jan 25, 2017 by admin

19 Responses

0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Jun 21, 2016 by cdent_plus_os_at_ant (12,800 points)   2 2 6
0 votes

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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2016 by Sylvain_Bauza (14,100 points)   1 3 6
0 votes

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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2016 by Jay_Pipes (59,760 points)   3 11 14
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2016 by Sean_Dague (66,200 points)   4 11 18
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2016 by Sylvain_Bauza (14,100 points)   1 3 6
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2016 by Doug_Hellmann (87,520 points)   3 4 13
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2016 by Sean_Dague (66,200 points)   4 11 18
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2016 by graham.hayes_at_hpe. (6,780 points)   1 2 2
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2016 by dstanek_at_dstanek.c (2,440 points)   1 2
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jun 21, 2016 by Clint_Byrum (40,940 points)   4 6 10
...