settingsLogin | Registersettings

[openstack-dev] [all] [api] Reminder: WSME is not being actively maintained

0 votes

Last summer Lucas Gomes and I were press ganged into becoming core on
WSME. Since then we've piecemeal been verifying bug fixes and generally
trying to keep things moving. However, from the beginning we both agreed
that WSME is not a web framework that we should be encouraging. Though
it looks like it started with very good intentions, it never really
reached a state where any of the following are true:

  • The WSME code is easy to understand and maintain.
  • WSME provides correct handling of HTTP (notably response status
    and headers).
  • WSME has an architecture that is suitable for creating modern
    Python-based web applications.

Last summer we naively suggested that projects that are using it move to
using something else. That suggestion did not take into account the
realities of OpenStack.

So we need to come up with a new plan. Lucas and I can continue to
merge bug fixes as people provide them (and we become aware of them) and
we can continue to hassle Doug Hellman to make a release when one is
necessary but this does little to address the three gaps above nor the
continued use of the framework in existing projects.

Ideas?

Thanks.

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

asked Mar 8, 2016 in openstack-dev by cdent_plus_os_at_ant (12,800 points)   2 2 7

11 Responses

0 votes

Is there an estimate of how much work/time it would take to refactor the
library to slowly satisfy those three points?
Also, do we already have clear ideas on where we want to get? While the
three points are clear from a general point of view, what does each of
those points really mean? Which parts have you identified as "not easy to
understand", what architecture you have in mind when speaking about "modern
Python-based web applications"? IIRC you suggested Pecan as a reference.

About point #2, I think it could be the "easiest" to fix, even thou not so
elegantly at first, but I only see one bug report currently open about it (
https://bugs.launchpad.net/wsme/+bug/1532704). The first step here would be
to check the most common return codes used in APIs and see if WSME supports
them or not... (*)

IMHO, if we are trying to fix it, the first step should be to have a clear
plan as to encourage volunteer contributions, even thou there are not many
of those.

That's my 2 cents!

Cheers,
Stéphane

(*) I remember that a change I did to correct an HTTP status code returned
from WSME had an impact in the OpenStack projects using it. So before
releasing a version with the correct status codes we have to remember to
tell others to check their code to ensure it works with the correct status
codes.

On Tue, Mar 8, 2016 at 12:25 PM, Chris Dent cdent+os@anticdent.org wrote:

Last summer Lucas Gomes and I were press ganged into becoming core on
WSME. Since then we've piecemeal been verifying bug fixes and generally
trying to keep things moving. However, from the beginning we both agreed
that WSME is not a web framework that we should be encouraging. Though
it looks like it started with very good intentions, it never really
reached a state where any of the following are true:

  • The WSME code is easy to understand and maintain.
  • WSME provides correct handling of HTTP (notably response status
    and headers).
  • WSME has an architecture that is suitable for creating modern
    Python-based web applications.

Last summer we naively suggested that projects that are using it move to
using something else. That suggestion did not take into account the
realities of OpenStack.

So we need to come up with a new plan. Lucas and I can continue to
merge bug fixes as people provide them (and we become aware of them) and
we can continue to hassle Doug Hellman to make a release when one is
necessary but this does little to address the three gaps above nor the
continued use of the framework in existing projects.

Ideas?

Thanks.

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

--
Stéphane


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 Mar 8, 2016 by Stéphane_Bisinger (220 points)  
0 votes

On Tue, 8 Mar 2016, Stéphane Bisinger wrote:

Is there an estimate of how much work/time it would take to refactor the
library to slowly satisfy those three points?

No, that is the biggest reason I'm calling it unmaintained. Neither
Lucas nor I have the time nor interest in being the people who fix WSME
so no estimating has been done.

Also, do we already have clear ideas on where we want to get? While the
three points are clear from a general point of view, what does each of
those points really mean? Which parts have you identified as "not easy to
understand", what architecture you have in mind when speaking about "modern
Python-based web applications"? IIRC you suggested Pecan as a reference.

I may have mentioned Pecan as a useful way to transition away from
WSME because many people who are using WSME are actually using
WSME+Pecan and its not that hard to extract the WSME parts and
replace the input and output handling with voluptuous or something
like that.

However I don't like Pecan myself because it models URL routing using
object-dispatch which I think is very bad for URL design. When we've
talked about this before Flask and Falcon were mooted. Flask
generally gets the nod because of its community but it requires a
commitment to doing things the "Flask way".

IMHO, if we are trying to fix it, the first step should be to have a clear
plan as to encourage volunteer contributions, even thou there are not many
of those.

That is pretty much the main question: Does OpenStack want to fix
it?

That's my 2 cents!

Thank you!

(*) I remember that a change I did to correct an HTTP status code returned
from WSME had an impact in the OpenStack projects using it. So before
releasing a version with the correct status codes we have to remember to
tell others to check their code to ensure it works with the correct status
codes.

Exactly. Projects that use OpenStack have habituated themselves to
some of the bad behaviors in WSME (I think at one point it was
returning 404 when it should have been 405) and written tests to
validate the bad behavior. Upgrading to a new WSME breaks their
tests.

--
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 Mar 8, 2016 by cdent_plus_os_at_ant (12,800 points)   2 2 7
0 votes

Which projects in OpenStack actually use WSME at this time?

Best,
-jay

On 03/08/2016 07:10 AM, Chris Dent wrote:
On Tue, 8 Mar 2016, Stéphane Bisinger wrote:

Is there an estimate of how much work/time it would take to refactor the
library to slowly satisfy those three points?

No, that is the biggest reason I'm calling it unmaintained. Neither
Lucas nor I have the time nor interest in being the people who fix WSME
so no estimating has been done.

Also, do we already have clear ideas on where we want to get? While the
three points are clear from a general point of view, what does each of
those points really mean? Which parts have you identified as "not easy to
understand", what architecture you have in mind when speaking about
"modern
Python-based web applications"? IIRC you suggested Pecan as a reference.

I may have mentioned Pecan as a useful way to transition away from
WSME because many people who are using WSME are actually using
WSME+Pecan and its not that hard to extract the WSME parts and
replace the input and output handling with voluptuous or something
like that.

However I don't like Pecan myself because it models URL routing using
object-dispatch which I think is very bad for URL design. When we've
talked about this before Flask and Falcon were mooted. Flask
generally gets the nod because of its community but it requires a
commitment to doing things the "Flask way".

IMHO, if we are trying to fix it, the first step should be to have a
clear
plan as to encourage volunteer contributions, even thou there are not
many
of those.

That is pretty much the main question: Does OpenStack want to fix
it?

That's my 2 cents!

Thank you!

(*) I remember that a change I did to correct an HTTP status code
returned
from WSME had an impact in the OpenStack projects using it. So before
releasing a version with the correct status codes we have to remember to
tell others to check their code to ensure it works with the correct
status
codes.

Exactly. Projects that use OpenStack have habituated themselves to
some of the bad behaviors in WSME (I think at one point it was
returning 404 when it should have been 405) and written tests to
validate the bad behavior. Upgrading to a new WSME breaks their
tests.


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 Mar 8, 2016 by Jay_Pipes (59,760 points)   3 12 19
0 votes

On Tue, 8 Mar 2016, Jay Pipes wrote:

Which projects in OpenStack actually use WSME at this time?

sdague and I were just talking about this and using
codesearch.openstack.org the list is something like (but probably
not completely accurate):

 aodh
 blazar
 ceilometer
 cerberus
 cloudkitty
 cue
 ekko
 glance
 ironic
 magnum
 mistral
 radar
 solum
 surveil
 terracotta
 watcher

--
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 Mar 8, 2016 by cdent_plus_os_at_ant (12,800 points)   2 2 7
0 votes

24 instances as shown by codesearch:
http://codesearch.openstack.org/?q=%5E(wsme%7CWSME)&i=nope&files=%5E.*requirements.txt&repos=

-- Dims

On Tue, Mar 8, 2016 at 7:41 AM, Jay Pipes jaypipes@gmail.com wrote:
Which projects in OpenStack actually use WSME at this time?

Best,
-jay

On 03/08/2016 07:10 AM, Chris Dent wrote:

On Tue, 8 Mar 2016, Stéphane Bisinger wrote:

Is there an estimate of how much work/time it would take to refactor the
library to slowly satisfy those three points?

No, that is the biggest reason I'm calling it unmaintained. Neither
Lucas nor I have the time nor interest in being the people who fix WSME
so no estimating has been done.

Also, do we already have clear ideas on where we want to get? While the
three points are clear from a general point of view, what does each of
those points really mean? Which parts have you identified as "not easy to
understand", what architecture you have in mind when speaking about
"modern
Python-based web applications"? IIRC you suggested Pecan as a reference.

I may have mentioned Pecan as a useful way to transition away from
WSME because many people who are using WSME are actually using
WSME+Pecan and its not that hard to extract the WSME parts and
replace the input and output handling with voluptuous or something
like that.

However I don't like Pecan myself because it models URL routing using
object-dispatch which I think is very bad for URL design. When we've
talked about this before Flask and Falcon were mooted. Flask
generally gets the nod because of its community but it requires a
commitment to doing things the "Flask way".

IMHO, if we are trying to fix it, the first step should be to have a
clear
plan as to encourage volunteer contributions, even thou there are not
many
of those.

That is pretty much the main question: Does OpenStack want to fix
it?

That's my 2 cents!

Thank you!

(*) I remember that a change I did to correct an HTTP status code
returned
from WSME had an impact in the OpenStack projects using it. So before
releasing a version with the correct status codes we have to remember to
tell others to check their code to ensure it works with the correct
status
codes.

Exactly. Projects that use OpenStack have habituated themselves to
some of the bad behaviors in WSME (I think at one point it was
returning 404 when it should have been 405) and written tests to
validate the bad behavior. Upgrading to a new WSME breaks their
tests.


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

--
Davanum Srinivas :: https://twitter.com/dims


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 Mar 8, 2016 by Davanum_Srinivas (35,920 points)   2 5 16
0 votes

Excerpts from Chris Dent's message of 2016-03-08 11:25:48 +0000:

Last summer Lucas Gomes and I were press ganged into becoming core on
WSME. Since then we've piecemeal been verifying bug fixes and generally
trying to keep things moving. However, from the beginning we both agreed
that WSME is not a web framework that we should be encouraging. Though
it looks like it started with very good intentions, it never really
reached a state where any of the following are true:

  • The WSME code is easy to understand and maintain.
  • WSME provides correct handling of HTTP (notably response status
    and headers).
  • WSME has an architecture that is suitable for creating modern
    Python-based web applications.

Last summer we naively suggested that projects that are using it move to
using something else. That suggestion did not take into account the
realities of OpenStack.

So we need to come up with a new plan. Lucas and I can continue to
merge bug fixes as people provide them (and we become aware of them) and
we can continue to hassle Doug Hellman to make a release when one is
necessary but this does little to address the three gaps above nor the
continued use of the framework in existing projects.

Ideas?

One big reason for choosing WSME early on was that it had support
for both XML and JSON APIs without the application code needing to
do anything explicitly. In the time since projects started using
WSME, the community has decided to stop providing XML API support
and some other tools have been picked up (JSONSchema, Voluptuous,
etc.) that provide parsing and validation features similar to WSME.
It seems natural that we build new APIs using those tools instead
of WSME. For existing functioning API endpoints, we can leave them
alone (using WSME) or change them one at a time as they are extended
with new features. I don't see any reason to rewrite anything just
to change tools.

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 Mar 8, 2016 by Doug_Hellmann (87,520 points)   4 6 15
0 votes

On 08/03/2016 6:25 AM, Chris Dent wrote:

Last summer Lucas Gomes and I were press ganged into becoming core on
WSME. Since then we've piecemeal been verifying bug fixes and generally
trying to keep things moving. However, from the beginning we both agreed
that WSME is not a web framework that we should be encouraging. Though
it looks like it started with very good intentions, it never really
reached a state where any of the following are true:

  • The WSME code is easy to understand and maintain.
  • WSME provides correct handling of HTTP (notably response status
    and headers).
  • WSME has an architecture that is suitable for creating modern
    Python-based web applications.

Last summer we naively suggested that projects that are using it move to
using something else. That suggestion did not take into account the
realities of OpenStack.

So we need to come up with a new plan. Lucas and I can continue to
merge bug fixes as people provide them (and we become aware of them) and
we can continue to hassle Doug Hellman to make a release when one is
necessary but this does little to address the three gaps above nor the
continued use of the framework in existing projects.

Ideas?

it seems like the main reason there are so many projects leveraging WSME
is because everyone is just using Ironic or Ceilometer as the starting
point for their APIs. can we officially say to all new projects who plan
on copying API logic of Ironic et al.: 'stop'.

what are the viable alternatives out there? Voluptuous, JSONSchema? i
apologies, i know this is a question that gets asked every few months.

cheers,

--
gord


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 Mar 8, 2016 by gordon_chung (19,300 points)   2 3 13
0 votes

Excerpts from gordon chung's message of 2016-03-08 21:22:11 +0000:

On 08/03/2016 6:25 AM, Chris Dent wrote:

Last summer Lucas Gomes and I were press ganged into becoming core on
WSME. Since then we've piecemeal been verifying bug fixes and generally
trying to keep things moving. However, from the beginning we both agreed
that WSME is not a web framework that we should be encouraging. Though
it looks like it started with very good intentions, it never really
reached a state where any of the following are true:

  • The WSME code is easy to understand and maintain.
  • WSME provides correct handling of HTTP (notably response status
    and headers).
  • WSME has an architecture that is suitable for creating modern
    Python-based web applications.

Last summer we naively suggested that projects that are using it move to
using something else. That suggestion did not take into account the
realities of OpenStack.

So we need to come up with a new plan. Lucas and I can continue to
merge bug fixes as people provide them (and we become aware of them) and
we can continue to hassle Doug Hellman to make a release when one is
necessary but this does little to address the three gaps above nor the
continued use of the framework in existing projects.

Ideas?

it seems like the main reason there are so many projects leveraging WSME
is because everyone is just using Ironic or Ceilometer as the starting
point for their APIs. can we officially say to all new projects who plan
on copying API logic of Ironic et al.: 'stop'.

Sure. We should probably provide an alternative suggestion.

what are the viable alternatives out there? Voluptuous, JSONSchema? i
apologies, i know this is a question that gets asked every few months.


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 Mar 8, 2016 by Doug_Hellmann (87,520 points)   4 6 15
0 votes

Le 08/03/2016 22:22, gordon chung a écrit :

it seems like the main reason there are so many projects leveraging WSME
is because everyone is just using Ironic or Ceilometer as the starting
point for their APIs. can we officially say to all new projects who plan
on copying API logic of Ironic et al.: 'stop'.

Or maybe start to upgrade these two projects to use the state of the
art, since they look to be used as example :-)

Victor


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 Mar 9, 2016 by vstinner_at_redhat.c (5,420 points)   2 6 8
0 votes

On 03/08/2016 04:44 PM, Doug Hellmann wrote:

it seems like the main reason there are so many projects leveraging WSME
is because everyone is just using Ironic or Ceilometer as the starting
point for their APIs. can we officially say to all new projects who plan
on copying API logic of Ironic et al.: 'stop'.

Sure. We should probably provide an alternative suggestion.

just wanted to mention, for the record, that sahara is using flask for
it's http impl. i am also working on some example usages of flask that
show off the api-wg guidelines. i'd be happy to help any projects that
are looking to move in this direction.

regards,
mike


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 Mar 9, 2016 by michael_mccune (5,080 points)   3 4
...