Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained
I think we'd better to have a clear guidance here. For projects that are currently using WSME, should they have a plan to migrate to other tools? If yes, is there any suggestion for the replacement tools? I think it will be more clear to have an official guideline in this matter. Best regards, Hongbin -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: March-08-16 10:51 AM To: openstack-dev Subject: Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained Excerpts from Chris Dent's message of 2016-03-08 11:25:48 +: > > 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-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] [all] [api] Reminder: WSME is not being actively maintained
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained
Excerpts from gordon chung's message of 2016-03-08 21:22:11 +: > > 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained
Excerpts from Chris Dent's message of 2016-03-08 11:25:48 +: > > 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained
24 instances as shown by codesearch: http://codesearch.openstack.org/?q=%5E(wsme%7CWSME)=nope=%5E.*requirements.txt= -- Dims On Tue, Mar 8, 2016 at 7:41 AM, Jay Pipeswrote: > 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-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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [all] [api] Reminder: WSME is not being actively maintained
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 (�s°□°)�s�喋擤ォ�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] [all] [api] Reminder: WSME is not being actively maintained
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-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] [all] [api] Reminder: WSME is not being actively maintained
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained
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 Dentwrote: > > 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] [api] Reminder: WSME is not being actively maintained
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 (�s°□°)�s�喋擤ォ�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