Re: [openstack-dev] [Fuel][Nailgun] Web framework
Hello all, What is the current situation with choosing web framework? Was there any progress in the topic? I would like to avoid forgetting about it. 2014-12-08 15:47 GMT+01:00 Ryan Petrello ryan.petre...@dreamhost.com: Feel free to ask any questions you have in #pecanpy on IRC; I can answer a lot more quickly than researching docs, and if you have a special need, I can usually accommodate with changes to Pecan (I've done so with several OpenStack projects in the past). On 12/08/14 02:10 PM, Nikolay Markov wrote: Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. We still need some research to do about technical issues and how easy we can move to Pecan. Thanks to Ryan, we now have multiple links to solutions and docs on discussed issues. I guess we'll dedicate some engineer(s) responsible for doing such a research and then make all our decisions on subject. On Mon, Dec 8, 2014 at 11:07 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com: Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). IMHO small, iterative changes are rather obvious. For other questions maybe we need (draft of ) a blueprint and a separate mail thread? - Igor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Petrello Senior Developer, DreamHost ryan.petre...@dreamhost.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Hi Sebastian, Nobody is forgetting this topic, especially me :) We're going to dedicate an engineer to do some research on topic based on Ryan's comments and my old pull request on Nailgun with Pecan. The only thing is that it's not very high priority topic in our roadmap. Don't worry, I'm sure we'll get to it already in January. 30 Дек 2014 г. 15:25 пользователь Sebastian Kalinowski skalinow...@mirantis.com написал: Hello all, What is the current situation with choosing web framework? Was there any progress in the topic? I would like to avoid forgetting about it. 2014-12-08 15:47 GMT+01:00 Ryan Petrello ryan.petre...@dreamhost.com: Feel free to ask any questions you have in #pecanpy on IRC; I can answer a lot more quickly than researching docs, and if you have a special need, I can usually accommodate with changes to Pecan (I've done so with several OpenStack projects in the past). On 12/08/14 02:10 PM, Nikolay Markov wrote: Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. We still need some research to do about technical issues and how easy we can move to Pecan. Thanks to Ryan, we now have multiple links to solutions and docs on discussed issues. I guess we'll dedicate some engineer(s) responsible for doing such a research and then make all our decisions on subject. On Mon, Dec 8, 2014 at 11:07 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com: Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). IMHO small, iterative changes are rather obvious. For other questions maybe we need (draft of ) a blueprint and a separate mail thread? - Igor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Petrello Senior Developer, DreamHost ryan.petre...@dreamhost.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com: Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). IMHO small, iterative changes are rather obvious. For other questions maybe we need (draft of ) a blueprint and a separate mail thread? - Igor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. We still need some research to do about technical issues and how easy we can move to Pecan. Thanks to Ryan, we now have multiple links to solutions and docs on discussed issues. I guess we'll dedicate some engineer(s) responsible for doing such a research and then make all our decisions on subject. On Mon, Dec 8, 2014 at 11:07 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com: Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). IMHO small, iterative changes are rather obvious. For other questions maybe we need (draft of ) a blueprint and a separate mail thread? - Igor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Feel free to ask any questions you have in #pecanpy on IRC; I can answer a lot more quickly than researching docs, and if you have a special need, I can usually accommodate with changes to Pecan (I've done so with several OpenStack projects in the past). On 12/08/14 02:10 PM, Nikolay Markov wrote: Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. We still need some research to do about technical issues and how easy we can move to Pecan. Thanks to Ryan, we now have multiple links to solutions and docs on discussed issues. I guess we'll dedicate some engineer(s) responsible for doing such a research and then make all our decisions on subject. On Mon, Dec 8, 2014 at 11:07 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com: Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). IMHO small, iterative changes are rather obvious. For other questions maybe we need (draft of ) a blueprint and a separate mail thread? - Igor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Petrello Senior Developer, DreamHost ryan.petre...@dreamhost.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). - Igor On Wed, Dec 3, 2014 at 7:25 PM, Fox, Kevin M kevin@pnnl.gov wrote: Choosing the right instrument for the job in an open source community involves choosing technologies that the community is familiar/comfortable with as well, as it will allow you access to a greater pool of developers. With that in mind then, I'd add: Pro Pecan, blessed by the OpenStack community, con Flask, not. Kevin From: Nikolay Markov [nmar...@mirantis.com] Sent: Wednesday, December 03, 2014 9:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Fuel][Nailgun] Web framework I didn't participate in that discussion, but here are topics on Flask cons from your link. I added some comments. - Cons - db transactions a little trickier to manage, but possible # what is trickier? Flask uses pure SQLalchemy or a very thin wrapper - JSON built-in but not XML # the only one I agree with, but does Pecan have it? - some issues, not updated in a while # last commit was 3 days ago - No Python 3 support # full Python 3 support fro a year or so already - Not WebOb # can it even be considered as a con? I'm not trying to argue with you or community principles, I'm just trying to choose the right instrument for the job. On Wed, Dec 3, 2014 at 7:41 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/03/2014 10:53 AM, Nikolay Markov wrote: However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. I completely agree with you, Jay, but the same principle may be applied much wider. Why Openstack Community decided to use its own unstable project instead of existing solution, which is widely used in Python community? To avoid being a team player? Or, at least, why it's recommended way even if it doesn't provide the same features other frameworks have for a long time already? I mean, there is no doubt everyone would use stable and technically advanced tool, but imposing everyone to use it by force with a simple hope that it'll become better from this is usually a bad approach. This conversation was had a long time ago, was thoroughly thought-out and discussed at prior summits and the ML: https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks https://etherpad.openstack.org/p/havana-common-wsgi I think it's unfair to suggest that the OpenStack community decided to use its own unstable project instead of existing solution. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
I’d rather suggest doing in several iteration by replacing several resources by Pecan’s implementations. Doing that in one big patch-set will make reviewing very painful, so some bad things might be not noticed. On 04 Dec 2014, at 14:01, Igor Kalnitsky ikalnit...@mirantis.com wrote: Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). - Igor On Wed, Dec 3, 2014 at 7:25 PM, Fox, Kevin M kevin@pnnl.gov wrote: Choosing the right instrument for the job in an open source community involves choosing technologies that the community is familiar/comfortable with as well, as it will allow you access to a greater pool of developers. With that in mind then, I'd add: Pro Pecan, blessed by the OpenStack community, con Flask, not. Kevin From: Nikolay Markov [nmar...@mirantis.com] Sent: Wednesday, December 03, 2014 9:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Fuel][Nailgun] Web framework I didn't participate in that discussion, but here are topics on Flask cons from your link. I added some comments. - Cons - db transactions a little trickier to manage, but possible # what is trickier? Flask uses pure SQLalchemy or a very thin wrapper - JSON built-in but not XML # the only one I agree with, but does Pecan have it? - some issues, not updated in a while # last commit was 3 days ago - No Python 3 support # full Python 3 support fro a year or so already - Not WebOb # can it even be considered as a con? I'm not trying to argue with you or community principles, I'm just trying to choose the right instrument for the job. On Wed, Dec 3, 2014 at 7:41 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/03/2014 10:53 AM, Nikolay Markov wrote: However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. I completely agree with you, Jay, but the same principle may be applied much wider. Why Openstack Community decided to use its own unstable project instead of existing solution, which is widely used in Python community? To avoid being a team player? Or, at least, why it's recommended way even if it doesn't provide the same features other frameworks have for a long time already? I mean, there is no doubt everyone would use stable and technically advanced tool, but imposing everyone to use it by force with a simple hope that it'll become better from this is usually a bad approach. This conversation was had a long time ago, was thoroughly thought-out and discussed at prior summits and the ML: https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks https://etherpad.openstack.org/p/havana-common-wsgi I think it's unfair to suggest that the OpenStack community decided to use its own unstable project instead of existing solution. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Ryan, can you please provide some more links on how these features what I described are implemented in Pecan? Some working examples, maybe? As far as I see now, each OpenStack project uses its own approach to integration with Pecan, so what will you recommend to look at? On Thu, Dec 4, 2014 at 4:10 PM, Roman Prykhodchenko rprikhodche...@mirantis.com wrote: I’d rather suggest doing in several iteration by replacing several resources by Pecan’s implementations. Doing that in one big patch-set will make reviewing very painful, so some bad things might be not noticed. On 04 Dec 2014, at 14:01, Igor Kalnitsky ikalnit...@mirantis.com wrote: Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). - Igor On Wed, Dec 3, 2014 at 7:25 PM, Fox, Kevin M kevin@pnnl.gov wrote: Choosing the right instrument for the job in an open source community involves choosing technologies that the community is familiar/comfortable with as well, as it will allow you access to a greater pool of developers. With that in mind then, I'd add: Pro Pecan, blessed by the OpenStack community, con Flask, not. Kevin From: Nikolay Markov [nmar...@mirantis.com] Sent: Wednesday, December 03, 2014 9:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Fuel][Nailgun] Web framework I didn't participate in that discussion, but here are topics on Flask cons from your link. I added some comments. - Cons - db transactions a little trickier to manage, but possible # what is trickier? Flask uses pure SQLalchemy or a very thin wrapper - JSON built-in but not XML # the only one I agree with, but does Pecan have it? - some issues, not updated in a while # last commit was 3 days ago - No Python 3 support # full Python 3 support fro a year or so already - Not WebOb # can it even be considered as a con? I'm not trying to argue with you or community principles, I'm just trying to choose the right instrument for the job. On Wed, Dec 3, 2014 at 7:41 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/03/2014 10:53 AM, Nikolay Markov wrote: However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. I completely agree with you, Jay, but the same principle may be applied much wider. Why Openstack Community decided to use its own unstable project instead of existing solution, which is widely used in Python community? To avoid being a team player? Or, at least, why it's recommended way even if it doesn't provide the same features other frameworks have for a long time already? I mean, there is no doubt everyone would use stable and technically advanced tool, but imposing everyone to use it by force with a simple hope that it'll become better from this is usually a bad approach. This conversation was had a long time ago, was thoroughly thought-out and discussed at prior summits and the ML: https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks https://etherpad.openstack.org/p/havana-common-wsgi I think it's unfair to suggest that the OpenStack community decided to use its own unstable project instead of existing solution. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Nikolay, I'd recommend taking a look at the work I did for the Barbican project in converting their falcon-based API to pecan: https://review.openstack.org/#/c/89746 ...because it makes use of a pecan feature called generic controllers for defining RESTful interfaces: https://review.openstack.org/#/c/138887/ The approach that most people in the OpenStack community have taken (probably because Ceilometer did so first, and provided a canonical implementation), the use of `pecan.rest.RestController`, is something we added to pecan to support compatability with TurboGears2. In my opinion, RestController is quite confusing, and overkill for what most APIs need - I recommend that people *not* use RestController due to its complexity, which mainly stems from TG2 compatability). I'm also working today on improving pecan's documentation as a result of some of the questions I've seen floating around in this thread. On 12/04/14 06:32 PM, Nikolay Markov wrote: Ryan, can you please provide some more links on how these features what I described are implemented in Pecan? Some working examples, maybe? As far as I see now, each OpenStack project uses its own approach to integration with Pecan, so what will you recommend to look at? On Thu, Dec 4, 2014 at 4:10 PM, Roman Prykhodchenko rprikhodche...@mirantis.com wrote: I’d rather suggest doing in several iteration by replacing several resources by Pecan’s implementations. Doing that in one big patch-set will make reviewing very painful, so some bad things might be not noticed. On 04 Dec 2014, at 14:01, Igor Kalnitsky ikalnit...@mirantis.com wrote: Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). - Igor On Wed, Dec 3, 2014 at 7:25 PM, Fox, Kevin M kevin@pnnl.gov wrote: Choosing the right instrument for the job in an open source community involves choosing technologies that the community is familiar/comfortable with as well, as it will allow you access to a greater pool of developers. With that in mind then, I'd add: Pro Pecan, blessed by the OpenStack community, con Flask, not. Kevin From: Nikolay Markov [nmar...@mirantis.com] Sent: Wednesday, December 03, 2014 9:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Fuel][Nailgun] Web framework I didn't participate in that discussion, but here are topics on Flask cons from your link. I added some comments. - Cons - db transactions a little trickier to manage, but possible # what is trickier? Flask uses pure SQLalchemy or a very thin wrapper - JSON built-in but not XML # the only one I agree with, but does Pecan have it? - some issues, not updated in a while # last commit was 3 days ago - No Python 3 support # full Python 3 support fro a year or so already - Not WebOb # can it even be considered as a con? I'm not trying to argue with you or community principles, I'm just trying to choose the right instrument for the job. On Wed, Dec 3, 2014 at 7:41 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/03/2014 10:53 AM, Nikolay Markov wrote: However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. I completely agree with you, Jay, but the same principle may be applied much wider. Why Openstack Community decided to use its own unstable project instead of existing solution, which is widely used in Python community? To avoid being a team player? Or, at least, why it's recommended way even if it doesn't provide the same features other frameworks have for a long time already? I mean, there is no doubt everyone would use stable and technically advanced tool, but imposing everyone to use it by force with a simple hope that it'll become better from this is usually a bad approach. This conversation was had a long time ago, was thoroughly thought-out and discussed at prior summits and the ML: https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks https://etherpad.openstack.org/p/havana-common-wsgi I think it's unfair to suggest that the OpenStack community decided to use its own unstable project instead of existing solution. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http
Re: [openstack-dev] [Fuel][Nailgun] Web framework
We had used Flask in the fuel-stats. It was easy and pleasant and all project requirements was satisfied. And I saw difficulties and workarounds with Pecan, when Nick integrated it into Nailgun. So +1 for Flask. On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov nmar...@mirantis.com wrote: Michael, we already solved all issues I described, and I just don't want to solve them once again after moving to another framework. Also, I think, nothing of these wishes contradicts with good API design. On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck krotsch...@gmail.com wrote: This sounds more like you need to pay off technical debt and clean up your API. Michael On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov nmar...@mirantis.com wrote: Hello all, I actually tried to use Pecan and even created a couple of PoCs, but there due to historical reasons of how our API is organized it will take much more time to implement all workarounds we need to issues Pecan doesn't solve out of the box, like working with non-RESTful URLs, reverse URL lookup, returning custom body in 404 response, wrapping errors to JSON automatically, etc. As far as I see, each OpenStack project implements its own workarounds for these issues, but still it requires much less men and hours for us to move to Flask-Restful instead of Pecan, because all these problems are already solved there. BTW, I know a lot of pretty big projects using Flask (it's the second most popular Web framework after Django in Python Web community), they even have their own hall of fame: http://flask.pocoo.org/community/poweredby/ . On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown rybr...@redhat.com wrote: On 12/02/2014 09:55 AM, Igor Kalnitsky wrote: Hi, Sebastian, Thank you for raising this topic again. [snip] Personally, I'd like to use Flask instead of Pecan, because first one is more production-ready tool and I like its design. But I believe this should be resolved by voting. Thanks, Igor On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi all, [snip explanation+history] Best, Sebastian Given that Pecan is used for other OpenStack projects and has plenty of builtin functionality (REST support, sessions, etc) I'd prefer it for a number of reasons. 1) Wouldn't have to pull in plugins for standard (in Pecan) things 2) Pecan is built for high traffic, where Flask is aimed at much smaller projects 3) Already used by other OpenStack projects, so common patterns can be reused as oslo libs Of course, the Flask community seems larger (though the average flask project seems pretty small). I'm not sure what determines production readiness, but it seems to me like Fuel developers fall more in Pecan's target audience than in Flask's. My $0.02, Ryan -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Well, I think if the general direction is to make Fuel using OpenStack tools and libraries as much as it's possible, that makes sense to use Pecan. Otherwise I'd prefer to swap web.py with Flask. Sincerely yours, Ivan Kliuk On 12/2/14 16:55, Igor Kalnitsky wrote: Hi, Sebastian, Thank you for raising this topic again. Yes, indeed, we need to move out from web.py as soon as possible and there are a lot of reasons why we should do it. But this topic is not about Why, this topic is about Flask or Pecan. Well, currently Fuel uses both of this frameworks: * OSTF is using Pecan * Fuel Stats is using Flask Personally, I'd like to use Flask instead of Pecan, because first one is more production-ready tool and I like its design. But I believe this should be resolved by voting. Thanks, Igor On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi all, Some time ago we had a discussion about moving Nailgun to new web framework [1]. There was comparison [2] of two possible options: Pecan [3] and Flask [4]. We came to conclusion that we need to move Nailgun on some alive web framework instead of web.py [5] (some of the reasons: [6]) but there was no clear agreement on what framework (there were strong voices for Flask). I would like to bring this topic up again so we could discuss with broader audience and make final decision what will be our next web framework. I think that we should also consider to make that framework our weapon of choice (or so called standard) when creating new web services in Fuel. Best, Sebastian [1] https://lists.launchpad.net/fuel-dev/msg01397.html [2] https://docs.google.com/a/mirantis.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing [3] http://www.pecanpy.org/ [4] http://flask.pocoo.org/ [5] http://webpy.org/ [6] https://lists.launchpad.net/fuel-dev/msg01501.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
The only useful paradigm to write in Flask is MethodView's for me [1] because decorators seem hard to refactor for large projects. Please look at adding URLs -- one has to additionally specify methods to match those from the MethodView -- this is code duplication and looks ugly. It seems though that Fask-RESTful [2] fixes this but then we're dependent on 2 projects. I don't like that Flask uses a global request object [3]. From Flask documentation Basically you can completely ignore that this is the case unless you are doing something like unit testing. You will notice that code which depends on a request object will suddenly break because there is no request object. The solution is creating a request object yourself and binding it to the context. Yeah, let's make testing even harder... Pecan looks better in respect of RESTful services [4]. POST parameters are cleanly passed as arguments to the post method. It also provides custom JSON serialization hooks [5] so we can forget about explicit serialization in handlers. So from these 2 choices I'm for Pecan. [1] http://flask.pocoo.org/docs/0.10/views/#method-views-for-apis [2] https://flask-restful.readthedocs.org/en/0.3.0/ [3] http://flask.pocoo.org/docs/0.10/quickstart/#accessing-request-data [4] http://pecan.readthedocs.org/en/latest/rest.html [5] http://pecan.readthedocs.org/en/latest/jsonify.html P. On 12/03/2014 10:57 AM, Alexander Kislitsky wrote: We had used Flask in the fuel-stats. It was easy and pleasant and all project requirements was satisfied. And I saw difficulties and workarounds with Pecan, when Nick integrated it into Nailgun. So +1 for Flask. On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov nmar...@mirantis.com mailto:nmar...@mirantis.com wrote: Michael, we already solved all issues I described, and I just don't want to solve them once again after moving to another framework. Also, I think, nothing of these wishes contradicts with good API design. On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck krotsch...@gmail.com mailto:krotsch...@gmail.com wrote: This sounds more like you need to pay off technical debt and clean up your API. Michael On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov nmar...@mirantis.com mailto:nmar...@mirantis.com wrote: Hello all, I actually tried to use Pecan and even created a couple of PoCs, but there due to historical reasons of how our API is organized it will take much more time to implement all workarounds we need to issues Pecan doesn't solve out of the box, like working with non-RESTful URLs, reverse URL lookup, returning custom body in 404 response, wrapping errors to JSON automatically, etc. As far as I see, each OpenStack project implements its own workarounds for these issues, but still it requires much less men and hours for us to move to Flask-Restful instead of Pecan, because all these problems are already solved there. BTW, I know a lot of pretty big projects using Flask (it's the second most popular Web framework after Django in Python Web community), they even have their own hall of fame: http://flask.pocoo.org/community/poweredby/ . On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown rybr...@redhat.com mailto:rybr...@redhat.com wrote: On 12/02/2014 09:55 AM, Igor Kalnitsky wrote: Hi, Sebastian, Thank you for raising this topic again. [snip] Personally, I'd like to use Flask instead of Pecan, because first one is more production-ready tool and I like its design. But I believe this should be resolved by voting. Thanks, Igor On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski skalinow...@mirantis.com mailto:skalinow...@mirantis.com wrote: Hi all, [snip explanation+history] Best, Sebastian Given that Pecan is used for other OpenStack projects and has plenty of builtin functionality (REST support, sessions, etc) I'd prefer it for a number of reasons. 1) Wouldn't have to pull in plugins for standard (in Pecan) things 2) Pecan is built for high traffic, where Flask is aimed at much smaller projects 3) Already used by other OpenStack projects, so common patterns can be reused as oslo libs Of course, the Flask community seems larger (though the average flask project seems pretty small). I'm not sure what determines production readiness, but it seems to me like Fuel developers fall more in Pecan's target audience than in Flask's. My $0.02, Ryan -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Additionaly to what Przemek wrote, also Pecan is released more often, IMHO documentation is better written, and described a lot of possibilities of modification, also as Lukasz wrote in previous thread that Pecan is used in openstack. So I'm also for Pecan Best regards, Kamil S. On Wed, Dec 3, 2014 at 12:45 PM, Przemyslaw Kaminski pkamin...@mirantis.com wrote: The only useful paradigm to write in Flask is MethodView's for me [1] because decorators seem hard to refactor for large projects. Please look at adding URLs -- one has to additionally specify methods to match those from the MethodView -- this is code duplication and looks ugly. It seems though that Fask-RESTful [2] fixes this but then we're dependent on 2 projects. I don't like that Flask uses a global request object [3]. From Flask documentation Basically you can completely ignore that this is the case unless you are doing something like unit testing. You will notice that code which depends on a request object will suddenly break because there is no request object. The solution is creating a request object yourself and binding it to the context. Yeah, let's make testing even harder... Pecan looks better in respect of RESTful services [4]. POST parameters are cleanly passed as arguments to the post method. It also provides custom JSON serialization hooks [5] so we can forget about explicit serialization in handlers. So from these 2 choices I'm for Pecan. [1] http://flask.pocoo.org/docs/0.10/views/#method-views-for-apis [2] https://flask-restful.readthedocs.org/en/0.3.0/ [3] http://flask.pocoo.org/docs/0.10/quickstart/#accessing-request-data [4] http://pecan.readthedocs.org/en/latest/rest.html [5] http://pecan.readthedocs.org/en/latest/jsonify.html P. On 12/03/2014 10:57 AM, Alexander Kislitsky wrote: We had used Flask in the fuel-stats. It was easy and pleasant and all project requirements was satisfied. And I saw difficulties and workarounds with Pecan, when Nick integrated it into Nailgun. So +1 for Flask. On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov nmar...@mirantis.com wrote: Michael, we already solved all issues I described, and I just don't want to solve them once again after moving to another framework. Also, I think, nothing of these wishes contradicts with good API design. On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck krotsch...@gmail.com wrote: This sounds more like you need to pay off technical debt and clean up your API. Michael On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov nmar...@mirantis.com wrote: Hello all, I actually tried to use Pecan and even created a couple of PoCs, but there due to historical reasons of how our API is organized it will take much more time to implement all workarounds we need to issues Pecan doesn't solve out of the box, like working with non-RESTful URLs, reverse URL lookup, returning custom body in 404 response, wrapping errors to JSON automatically, etc. As far as I see, each OpenStack project implements its own workarounds for these issues, but still it requires much less men and hours for us to move to Flask-Restful instead of Pecan, because all these problems are already solved there. BTW, I know a lot of pretty big projects using Flask (it's the second most popular Web framework after Django in Python Web community), they even have their own hall of fame: http://flask.pocoo.org/community/poweredby/ . On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown rybr...@redhat.com wrote: On 12/02/2014 09:55 AM, Igor Kalnitsky wrote: Hi, Sebastian, Thank you for raising this topic again. [snip] Personally, I'd like to use Flask instead of Pecan, because first one is more production-ready tool and I like its design. But I believe this should be resolved by voting. Thanks, Igor On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi all, [snip explanation+history] Best, Sebastian Given that Pecan is used for other OpenStack projects and has plenty of builtin functionality (REST support, sessions, etc) I'd prefer it for a number of reasons. 1) Wouldn't have to pull in plugins for standard (in Pecan) things 2) Pecan is built for high traffic, where Flask is aimed at much smaller projects 3) Already used by other OpenStack projects, so common patterns can be reused as oslo libs Of course, the Flask community seems larger (though the average flask project seems pretty small). I'm not sure what determines production readiness, but it seems to me like Fuel developers fall more in Pecan's target audience than in Flask's. My $0.02, Ryan -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [Fuel][Nailgun] Web framework
I don't like that Flask uses a global request object [3]. Przemyslaw, actually Pecan does use global objects too. BTW, what's wrong with global objects? They are thread-safe in both Pecan and Flask. IMHO documentation is better written, and described a lot of possibilities of modification I disagree. Flask has rich documentation and more flexible, while Pecan forces us to use only its patterns and code organization. There are no possibilities to avoid this. I'm afraid with Pecan we will have to rewrite a lot of code. On Wed, Dec 3, 2014 at 2:21 PM, Kamil Sambor ksam...@mirantis.com wrote: Additionaly to what Przemek wrote, also Pecan is released more often, IMHO documentation is better written, and described a lot of possibilities of modification, also as Lukasz wrote in previous thread that Pecan is used in openstack. So I'm also for Pecan Best regards, Kamil S. On Wed, Dec 3, 2014 at 12:45 PM, Przemyslaw Kaminski pkamin...@mirantis.com wrote: The only useful paradigm to write in Flask is MethodView's for me [1] because decorators seem hard to refactor for large projects. Please look at adding URLs -- one has to additionally specify methods to match those from the MethodView -- this is code duplication and looks ugly. It seems though that Fask-RESTful [2] fixes this but then we're dependent on 2 projects. I don't like that Flask uses a global request object [3]. From Flask documentation Basically you can completely ignore that this is the case unless you are doing something like unit testing. You will notice that code which depends on a request object will suddenly break because there is no request object. The solution is creating a request object yourself and binding it to the context. Yeah, let's make testing even harder... Pecan looks better in respect of RESTful services [4]. POST parameters are cleanly passed as arguments to the post method. It also provides custom JSON serialization hooks [5] so we can forget about explicit serialization in handlers. So from these 2 choices I'm for Pecan. [1] http://flask.pocoo.org/docs/0.10/views/#method-views-for-apis [2] https://flask-restful.readthedocs.org/en/0.3.0/ [3] http://flask.pocoo.org/docs/0.10/quickstart/#accessing-request-data [4] http://pecan.readthedocs.org/en/latest/rest.html [5] http://pecan.readthedocs.org/en/latest/jsonify.html P. On 12/03/2014 10:57 AM, Alexander Kislitsky wrote: We had used Flask in the fuel-stats. It was easy and pleasant and all project requirements was satisfied. And I saw difficulties and workarounds with Pecan, when Nick integrated it into Nailgun. So +1 for Flask. On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov nmar...@mirantis.com wrote: Michael, we already solved all issues I described, and I just don't want to solve them once again after moving to another framework. Also, I think, nothing of these wishes contradicts with good API design. On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck krotsch...@gmail.com wrote: This sounds more like you need to pay off technical debt and clean up your API. Michael On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov nmar...@mirantis.com wrote: Hello all, I actually tried to use Pecan and even created a couple of PoCs, but there due to historical reasons of how our API is organized it will take much more time to implement all workarounds we need to issues Pecan doesn't solve out of the box, like working with non-RESTful URLs, reverse URL lookup, returning custom body in 404 response, wrapping errors to JSON automatically, etc. As far as I see, each OpenStack project implements its own workarounds for these issues, but still it requires much less men and hours for us to move to Flask-Restful instead of Pecan, because all these problems are already solved there. BTW, I know a lot of pretty big projects using Flask (it's the second most popular Web framework after Django in Python Web community), they even have their own hall of fame: http://flask.pocoo.org/community/poweredby/ . On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown rybr...@redhat.com wrote: On 12/02/2014 09:55 AM, Igor Kalnitsky wrote: Hi, Sebastian, Thank you for raising this topic again. [snip] Personally, I'd like to use Flask instead of Pecan, because first one is more production-ready tool and I like its design. But I believe this should be resolved by voting. Thanks, Igor On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi all, [snip explanation+history] Best, Sebastian Given that Pecan is used for other OpenStack projects and has plenty of builtin functionality (REST support, sessions, etc) I'd prefer it for a number of reasons. 1) Wouldn't have to pull in plugins for standard (in Pecan) things 2) Pecan is built for high traffic, where Flask is aimed at much
Re: [openstack-dev] [Fuel][Nailgun] Web framework
2014-12-03 13:47 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com: I don't like that Flask uses a global request object [3]. Przemyslaw, actually Pecan does use global objects too. BTW, what's wrong with global objects? They are thread-safe in both Pecan and Flask. To be fair, Pecan could also pass request and response explicit to method [1] [1] http://pecan.readthedocs.org/en/latest/contextlocals.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Yeah, didn't notice that. Honestly, I'd prefer both to be accessible as instance attributes just like in [1] but it's more of taste I guess. [1] http://tornado.readthedocs.org/en/latest/web.html#tornado.web.RequestHandler.request P. On 12/03/2014 02:03 PM, Sebastian Kalinowski wrote: 2014-12-03 13:47 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com mailto:ikalnit...@mirantis.com: I don't like that Flask uses a global request object [3]. Przemyslaw, actually Pecan does use global objects too. BTW, what's wrong with global objects? They are thread-safe in both Pecan and Flask. To be fair, Pecan could also pass request and response explicit to method [1] [1] http://pecan.readthedocs.org/en/latest/contextlocals.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Dear colleagues, We surely may take into account the beauty of the code in both cases (as for me, Pecan loses here, too) and argue about global objects and stuff, but I'm trying to look at amount of men and time we need to move to one of these frameworks. I wouldn't say our API is badly designed, nevertheless Pecan still has a lot of issues needed to be fixed by hand. We don't want to spend much time to this task, because it is mostly the matter of convenience and simplicity for developers, it changes nothing in features or customer-facing behavior. And if we take in account the amount of hours we need to move, based on my experience Flask definitely wins here. On Wed, Dec 3, 2014 at 4:03 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2014-12-03 13:47 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com: I don't like that Flask uses a global request object [3]. Przemyslaw, actually Pecan does use global objects too. BTW, what's wrong with global objects? They are thread-safe in both Pecan and Flask. To be fair, Pecan could also pass request and response explicit to method [1] [1] http://pecan.readthedocs.org/en/latest/contextlocals.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
I never used Flask and Pecan personally so I can only rely from what I saw in this thread and in both projects docs. I don't have strong opinion, just want to share some thoughts. I think that as a part of OpenStack community we should stick with Pecan and because of the same reason we can have a bigger impact how future versions of Pecan will look. If we will choose Flask I see is that we not only need to choose a framework, but also decide which extension will be used to provide REST support (I do not like that we just assume flask-restful will be used). To be honest right now I'm more convinced that we should choose Pecan. 2014-12-03 14:22 GMT+01:00 Nikolay Markov nmar...@mirantis.com: Dear colleagues, We surely may take into account the beauty of the code in both cases (as for me, Pecan loses here, too) and argue about global objects and stuff, but I'm trying to look at amount of men and time we need to move to one of these frameworks. Agree that we should look on the man-hours for implementation, but I think that it is as important as all the small things like global object etc. since they could make future development painful or pleasant. I wouldn't say our API is badly designed, nevertheless Pecan still has a lot of issues needed to be fixed by hand. We don't want to spend much time to this task, because it is mostly the matter of convenience and simplicity for developers, it changes nothing in features or customer-facing behavior. And if we take in account the amount of hours we need to move, based on my experience Flask definitely wins here. Cannot we reuse the PoC ([1]) with Pecan that was created? There was a lot of work put into that piece of code. [1] https://review.openstack.org/#/c/99069/6 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
I don’t have an opinion for now but do have some thoughts instead. We use Pecan in Ironic. I could say that it’s pretty nice when one needs to make something simple but requires some manual job to be done in more or less sophisticated cases. On the other hand we have that the Pecan team is quire agile and open to other developers so we were able to merge our patches without any problems. However, if there is a framework that fits Nailgun's needs without being patched, that may be easier for us to just use it. There’s a political side of the question as well but I’d rather touch it only if both Flask and Pecan have the same pros and cons. - romcheg On 03 Dec 2014, at 14:22, Przemyslaw Kaminski pkamin...@mirantis.com wrote: Yeah, didn't notice that. Honestly, I'd prefer both to be accessible as instance attributes just like in [1] but it's more of taste I guess. [1] http://tornado.readthedocs.org/en/latest/web.html#tornado.web.RequestHandler.request http://tornado.readthedocs.org/en/latest/web.html#tornado.web.RequestHandler.request P. On 12/03/2014 02:03 PM, Sebastian Kalinowski wrote: 2014-12-03 13:47 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com mailto:ikalnit...@mirantis.com: I don't like that Flask uses a global request object [3]. Przemyslaw, actually Pecan does use global objects too. BTW, what's wrong with global objects? They are thread-safe in both Pecan and Flask. To be fair, Pecan could also pass request and response explicit to method [1] [1] http://pecan.readthedocs.org/en/latest/contextlocals.html http://pecan.readthedocs.org/en/latest/contextlocals.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
On 12/03/2014 09:35 AM, Sebastian Kalinowski wrote: I think that as a part of OpenStack community we should stick with Pecan and because of the same reason we can have a bigger impact how future versions of Pecan will look. Yes, this. ++ -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
It would be great to look at some obvious points where Pecan is better than Flask despite of the fact that it's used by the community. I still don't see a single and I don't think the principle jump from the cliff if everyone does works well in such cases. On Wed, Dec 3, 2014 at 5:53 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/03/2014 09:35 AM, Sebastian Kalinowski wrote: I think that as a part of OpenStack community we should stick with Pecan and because of the same reason we can have a bigger impact how future versions of Pecan will look. Yes, this. ++ -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Being able to make some impact on Pecan is an advantage for sure. But there are other aspects in choosing a web framework and I’d rather discuss them. Let’s not think about what is used in other OpenStack projects for a moment and discuss technical details. On 03 Dec 2014, at 15:53, Jay Pipes jaypi...@gmail.com wrote: On 12/03/2014 09:35 AM, Sebastian Kalinowski wrote: I think that as a part of OpenStack community we should stick with Pecan and because of the same reason we can have a bigger impact how future versions of Pecan will look. Yes, this. ++ -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
On 12/03/2014 10:16 AM, Nikolay Markov wrote: It would be great to look at some obvious points where Pecan is better than Flask despite of the fact that it's used by the community. I still don't see a single and I don't think the principle jump from the cliff if everyone does works well in such cases. This is part of why the Fuel development team is viewed as not working with the OpenStack community in many ways. The Fuel team is doing a remarkable job in changing previously-all-internal-to-Mirantis communication patterns to instead be on a transparent basis in the mailing lists and on IRC. I sincerely applaud the Fuel team for that. However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. It's expected that when you have an OpenStack REST API project, that you try to use the tools that the shared community uses, builds, and supports. Otherwise, you aren't being a team player. In the past, certain teams have chosen to use something other than Pecan due to technical reasons. For example, Zaqar's team chose to use the Falcon framework instead of the Pecan framework. Zaqar, like Swift, is a data API, not a control API, and raw performance is critical to the project's API endpoint). This is, incidentally, why the Swift team chose to use its swob framework over Webob (which Pecan uses). However, the reason that these were chosen was definitely not it doesn't support the coding patterns I like. There's something that comes from being a team player. And one of those things is going with the flow when there isn't a real technical reason not to. All of us can and do find things we don't like about *all* of the projects that we work on. The difference between team players and non-team players is that team players strongly weigh their decisions and opinions based on what the team is doing and how the team can improve. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. I completely agree with you, Jay, but the same principle may be applied much wider. Why Openstack Community decided to use its own unstable project instead of existing solution, which is widely used in Python community? To avoid being a team player? Or, at least, why it's recommended way even if it doesn't provide the same features other frameworks have for a long time already? I mean, there is no doubt everyone would use stable and technically advanced tool, but imposing everyone to use it by force with a simple hope that it'll become better from this is usually a bad approach. I personally would surely contribute to Pecan in case we decide to use it and there will be some gaps and uncovered cases. I'm just curious, does it worth it? On Wed, Dec 3, 2014 at 6:32 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/03/2014 10:16 AM, Nikolay Markov wrote: It would be great to look at some obvious points where Pecan is better than Flask despite of the fact that it's used by the community. I still don't see a single and I don't think the principle jump from the cliff if everyone does works well in such cases. This is part of why the Fuel development team is viewed as not working with the OpenStack community in many ways. The Fuel team is doing a remarkable job in changing previously-all-internal-to-Mirantis communication patterns to instead be on a transparent basis in the mailing lists and on IRC. I sincerely applaud the Fuel team for that. However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. It's expected that when you have an OpenStack REST API project, that you try to use the tools that the shared community uses, builds, and supports. Otherwise, you aren't being a team player. In the past, certain teams have chosen to use something other than Pecan due to technical reasons. For example, Zaqar's team chose to use the Falcon framework instead of the Pecan framework. Zaqar, like Swift, is a data API, not a control API, and raw performance is critical to the project's API endpoint). This is, incidentally, why the Swift team chose to use its swob framework over Webob (which Pecan uses). However, the reason that these were chosen was definitely not it doesn't support the coding patterns I like. There's something that comes from being a team player. And one of those things is going with the flow when there isn't a real technical reason not to. All of us can and do find things we don't like about *all* of the projects that we work on. The difference between team players and non-team players is that team players strongly weigh their decisions and opinions based on what the team is doing and how the team can improve. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
A month or two ago I started gathering differencies between Flask and Pecan, let's take a look at technical details. Maybe there are some things that are already fixed in current versions of Pecan, feel free to comment. https://docs.google.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing On Wed, Dec 3, 2014 at 6:53 PM, Nikolay Markov nmar...@mirantis.com wrote: However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. I completely agree with you, Jay, but the same principle may be applied much wider. Why Openstack Community decided to use its own unstable project instead of existing solution, which is widely used in Python community? To avoid being a team player? Or, at least, why it's recommended way even if it doesn't provide the same features other frameworks have for a long time already? I mean, there is no doubt everyone would use stable and technically advanced tool, but imposing everyone to use it by force with a simple hope that it'll become better from this is usually a bad approach. I personally would surely contribute to Pecan in case we decide to use it and there will be some gaps and uncovered cases. I'm just curious, does it worth it? On Wed, Dec 3, 2014 at 6:32 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/03/2014 10:16 AM, Nikolay Markov wrote: It would be great to look at some obvious points where Pecan is better than Flask despite of the fact that it's used by the community. I still don't see a single and I don't think the principle jump from the cliff if everyone does works well in such cases. This is part of why the Fuel development team is viewed as not working with the OpenStack community in many ways. The Fuel team is doing a remarkable job in changing previously-all-internal-to-Mirantis communication patterns to instead be on a transparent basis in the mailing lists and on IRC. I sincerely applaud the Fuel team for that. However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. It's expected that when you have an OpenStack REST API project, that you try to use the tools that the shared community uses, builds, and supports. Otherwise, you aren't being a team player. In the past, certain teams have chosen to use something other than Pecan due to technical reasons. For example, Zaqar's team chose to use the Falcon framework instead of the Pecan framework. Zaqar, like Swift, is a data API, not a control API, and raw performance is critical to the project's API endpoint). This is, incidentally, why the Swift team chose to use its swob framework over Webob (which Pecan uses). However, the reason that these were chosen was definitely not it doesn't support the coding patterns I like. There's something that comes from being a team player. And one of those things is going with the flow when there isn't a real technical reason not to. All of us can and do find things we don't like about *all* of the projects that we work on. The difference between team players and non-team players is that team players strongly weigh their decisions and opinions based on what the team is doing and how the team can improve. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
I didn't participate in that discussion, but here are topics on Flask cons from your link. I added some comments. - Cons - db transactions a little trickier to manage, but possible # what is trickier? Flask uses pure SQLalchemy or a very thin wrapper - JSON built-in but not XML # the only one I agree with, but does Pecan have it? - some issues, not updated in a while # last commit was 3 days ago - No Python 3 support # full Python 3 support fro a year or so already - Not WebOb # can it even be considered as a con? I'm not trying to argue with you or community principles, I'm just trying to choose the right instrument for the job. On Wed, Dec 3, 2014 at 7:41 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/03/2014 10:53 AM, Nikolay Markov wrote: However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. I completely agree with you, Jay, but the same principle may be applied much wider. Why Openstack Community decided to use its own unstable project instead of existing solution, which is widely used in Python community? To avoid being a team player? Or, at least, why it's recommended way even if it doesn't provide the same features other frameworks have for a long time already? I mean, there is no doubt everyone would use stable and technically advanced tool, but imposing everyone to use it by force with a simple hope that it'll become better from this is usually a bad approach. This conversation was had a long time ago, was thoroughly thought-out and discussed at prior summits and the ML: https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks https://etherpad.openstack.org/p/havana-common-wsgi I think it's unfair to suggest that the OpenStack community decided to use its own unstable project instead of existing solution. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
+1. Well said. I second the applauding of the Fuel's development team's for their changing of their communications patterns (that's never easy) and also the desire for closer integration with the rest of the OpenStack community. From: Jay Pipes [jaypi...@gmail.com] Sent: Wednesday, December 03, 2014 7:32 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Nailgun] Web framework On 12/03/2014 10:16 AM, Nikolay Markov wrote: It would be great to look at some obvious points where Pecan is better than Flask despite of the fact that it's used by the community. I still don't see a single and I don't think the principle jump from the cliff if everyone does works well in such cases. This is part of why the Fuel development team is viewed as not working with the OpenStack community in many ways. The Fuel team is doing a remarkable job in changing previously-all-internal-to-Mirantis communication patterns to instead be on a transparent basis in the mailing lists and on IRC. I sincerely applaud the Fuel team for that. However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. It's expected that when you have an OpenStack REST API project, that you try to use the tools that the shared community uses, builds, and supports. Otherwise, you aren't being a team player. In the past, certain teams have chosen to use something other than Pecan due to technical reasons. For example, Zaqar's team chose to use the Falcon framework instead of the Pecan framework. Zaqar, like Swift, is a data API, not a control API, and raw performance is critical to the project's API endpoint). This is, incidentally, why the Swift team chose to use its swob framework over Webob (which Pecan uses). However, the reason that these were chosen was definitely not it doesn't support the coding patterns I like. There's something that comes from being a team player. And one of those things is going with the flow when there isn't a real technical reason not to. All of us can and do find things we don't like about *all* of the projects that we work on. The difference between team players and non-team players is that team players strongly weigh their decisions and opinions based on what the team is doing and how the team can improve. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
I've left some comments/corrections in this document re: pecan and what is supports. On 12/03/14 07:58 PM, Nikolay Markov wrote: A month or two ago I started gathering differencies between Flask and Pecan, let's take a look at technical details. Maybe there are some things that are already fixed in current versions of Pecan, feel free to comment. https://docs.google.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing On Wed, Dec 3, 2014 at 6:53 PM, Nikolay Markov nmar...@mirantis.com wrote: However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. I completely agree with you, Jay, but the same principle may be applied much wider. Why Openstack Community decided to use its own unstable project instead of existing solution, which is widely used in Python community? To avoid being a team player? Or, at least, why it's recommended way even if it doesn't provide the same features other frameworks have for a long time already? I mean, there is no doubt everyone would use stable and technically advanced tool, but imposing everyone to use it by force with a simple hope that it'll become better from this is usually a bad approach. I personally would surely contribute to Pecan in case we decide to use it and there will be some gaps and uncovered cases. I'm just curious, does it worth it? On Wed, Dec 3, 2014 at 6:32 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/03/2014 10:16 AM, Nikolay Markov wrote: It would be great to look at some obvious points where Pecan is better than Flask despite of the fact that it's used by the community. I still don't see a single and I don't think the principle jump from the cliff if everyone does works well in such cases. This is part of why the Fuel development team is viewed as not working with the OpenStack community in many ways. The Fuel team is doing a remarkable job in changing previously-all-internal-to-Mirantis communication patterns to instead be on a transparent basis in the mailing lists and on IRC. I sincerely applaud the Fuel team for that. However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. It's expected that when you have an OpenStack REST API project, that you try to use the tools that the shared community uses, builds, and supports. Otherwise, you aren't being a team player. In the past, certain teams have chosen to use something other than Pecan due to technical reasons. For example, Zaqar's team chose to use the Falcon framework instead of the Pecan framework. Zaqar, like Swift, is a data API, not a control API, and raw performance is critical to the project's API endpoint). This is, incidentally, why the Swift team chose to use its swob framework over Webob (which Pecan uses). However, the reason that these were chosen was definitely not it doesn't support the coding patterns I like. There's something that comes from being a team player. And one of those things is going with the flow when there isn't a real technical reason not to. All of us can and do find things we don't like about *all* of the projects that we work on. The difference between team players and non-team players is that team players strongly weigh their decisions and opinions based on what the team is doing and how the team can improve. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Petrello Senior Developer, DreamHost ryan.petre...@dreamhost.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Choosing the right instrument for the job in an open source community involves choosing technologies that the community is familiar/comfortable with as well, as it will allow you access to a greater pool of developers. With that in mind then, I'd add: Pro Pecan, blessed by the OpenStack community, con Flask, not. Kevin From: Nikolay Markov [nmar...@mirantis.com] Sent: Wednesday, December 03, 2014 9:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Fuel][Nailgun] Web framework I didn't participate in that discussion, but here are topics on Flask cons from your link. I added some comments. - Cons - db transactions a little trickier to manage, but possible # what is trickier? Flask uses pure SQLalchemy or a very thin wrapper - JSON built-in but not XML # the only one I agree with, but does Pecan have it? - some issues, not updated in a while # last commit was 3 days ago - No Python 3 support # full Python 3 support fro a year or so already - Not WebOb # can it even be considered as a con? I'm not trying to argue with you or community principles, I'm just trying to choose the right instrument for the job. On Wed, Dec 3, 2014 at 7:41 PM, Jay Pipes jaypi...@gmail.com wrote: On 12/03/2014 10:53 AM, Nikolay Markov wrote: However, the OpenStack community is also about a shared set of tools, development methodologies, and common perspectives. I completely agree with you, Jay, but the same principle may be applied much wider. Why Openstack Community decided to use its own unstable project instead of existing solution, which is widely used in Python community? To avoid being a team player? Or, at least, why it's recommended way even if it doesn't provide the same features other frameworks have for a long time already? I mean, there is no doubt everyone would use stable and technically advanced tool, but imposing everyone to use it by force with a simple hope that it'll become better from this is usually a bad approach. This conversation was had a long time ago, was thoroughly thought-out and discussed at prior summits and the ML: https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks https://etherpad.openstack.org/p/havana-common-wsgi I think it's unfair to suggest that the OpenStack community decided to use its own unstable project instead of existing solution. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel][Nailgun] Web framework
Hi all, Some time ago we had a discussion about moving Nailgun to new web framework [1]. There was comparison [2] of two possible options: Pecan [3] and Flask [4]. We came to conclusion that we need to move Nailgun on some alive web framework instead of web.py [5] (some of the reasons: [6]) but there was no clear agreement on what framework (there were strong voices for Flask). I would like to bring this topic up again so we could discuss with broader audience and make final decision what will be our next web framework. I think that we should also consider to make that framework our weapon of choice (or so called standard) when creating new web services in Fuel. Best, Sebastian [1] https://lists.launchpad.net/fuel-dev/msg01397.html [2] https://docs.google.com/a/mirantis.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing [3] http://www.pecanpy.org/ [4] http://flask.pocoo.org/ [5] http://webpy.org/ [6] https://lists.launchpad.net/fuel-dev/msg01501.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Hi, Sebastian, Thank you for raising this topic again. Yes, indeed, we need to move out from web.py as soon as possible and there are a lot of reasons why we should do it. But this topic is not about Why, this topic is about Flask or Pecan. Well, currently Fuel uses both of this frameworks: * OSTF is using Pecan * Fuel Stats is using Flask Personally, I'd like to use Flask instead of Pecan, because first one is more production-ready tool and I like its design. But I believe this should be resolved by voting. Thanks, Igor On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi all, Some time ago we had a discussion about moving Nailgun to new web framework [1]. There was comparison [2] of two possible options: Pecan [3] and Flask [4]. We came to conclusion that we need to move Nailgun on some alive web framework instead of web.py [5] (some of the reasons: [6]) but there was no clear agreement on what framework (there were strong voices for Flask). I would like to bring this topic up again so we could discuss with broader audience and make final decision what will be our next web framework. I think that we should also consider to make that framework our weapon of choice (or so called standard) when creating new web services in Fuel. Best, Sebastian [1] https://lists.launchpad.net/fuel-dev/msg01397.html [2] https://docs.google.com/a/mirantis.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing [3] http://www.pecanpy.org/ [4] http://flask.pocoo.org/ [5] http://webpy.org/ [6] https://lists.launchpad.net/fuel-dev/msg01501.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
On 12/02/2014 09:55 AM, Igor Kalnitsky wrote: Hi, Sebastian, Thank you for raising this topic again. [snip] Personally, I'd like to use Flask instead of Pecan, because first one is more production-ready tool and I like its design. But I believe this should be resolved by voting. Thanks, Igor On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi all, [snip explanation+history] Best, Sebastian Given that Pecan is used for other OpenStack projects and has plenty of builtin functionality (REST support, sessions, etc) I'd prefer it for a number of reasons. 1) Wouldn't have to pull in plugins for standard (in Pecan) things 2) Pecan is built for high traffic, where Flask is aimed at much smaller projects 3) Already used by other OpenStack projects, so common patterns can be reused as oslo libs Of course, the Flask community seems larger (though the average flask project seems pretty small). I'm not sure what determines production readiness, but it seems to me like Fuel developers fall more in Pecan's target audience than in Flask's. My $0.02, Ryan -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Hello all, I actually tried to use Pecan and even created a couple of PoCs, but there due to historical reasons of how our API is organized it will take much more time to implement all workarounds we need to issues Pecan doesn't solve out of the box, like working with non-RESTful URLs, reverse URL lookup, returning custom body in 404 response, wrapping errors to JSON automatically, etc. As far as I see, each OpenStack project implements its own workarounds for these issues, but still it requires much less men and hours for us to move to Flask-Restful instead of Pecan, because all these problems are already solved there. BTW, I know a lot of pretty big projects using Flask (it's the second most popular Web framework after Django in Python Web community), they even have their own hall of fame: http://flask.pocoo.org/community/poweredby/ . On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown rybr...@redhat.com wrote: On 12/02/2014 09:55 AM, Igor Kalnitsky wrote: Hi, Sebastian, Thank you for raising this topic again. [snip] Personally, I'd like to use Flask instead of Pecan, because first one is more production-ready tool and I like its design. But I believe this should be resolved by voting. Thanks, Igor On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi all, [snip explanation+history] Best, Sebastian Given that Pecan is used for other OpenStack projects and has plenty of builtin functionality (REST support, sessions, etc) I'd prefer it for a number of reasons. 1) Wouldn't have to pull in plugins for standard (in Pecan) things 2) Pecan is built for high traffic, where Flask is aimed at much smaller projects 3) Already used by other OpenStack projects, so common patterns can be reused as oslo libs Of course, the Flask community seems larger (though the average flask project seems pretty small). I'm not sure what determines production readiness, but it seems to me like Fuel developers fall more in Pecan's target audience than in Flask's. My $0.02, Ryan -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
This sounds more like you need to pay off technical debt and clean up your API. Michael On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov nmar...@mirantis.com wrote: Hello all, I actually tried to use Pecan and even created a couple of PoCs, but there due to historical reasons of how our API is organized it will take much more time to implement all workarounds we need to issues Pecan doesn't solve out of the box, like working with non-RESTful URLs, reverse URL lookup, returning custom body in 404 response, wrapping errors to JSON automatically, etc. As far as I see, each OpenStack project implements its own workarounds for these issues, but still it requires much less men and hours for us to move to Flask-Restful instead of Pecan, because all these problems are already solved there. BTW, I know a lot of pretty big projects using Flask (it's the second most popular Web framework after Django in Python Web community), they even have their own hall of fame: http://flask.pocoo.org/community/poweredby/ . On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown rybr...@redhat.com wrote: On 12/02/2014 09:55 AM, Igor Kalnitsky wrote: Hi, Sebastian, Thank you for raising this topic again. [snip] Personally, I'd like to use Flask instead of Pecan, because first one is more production-ready tool and I like its design. But I believe this should be resolved by voting. Thanks, Igor On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi all, [snip explanation+history] Best, Sebastian Given that Pecan is used for other OpenStack projects and has plenty of builtin functionality (REST support, sessions, etc) I'd prefer it for a number of reasons. 1) Wouldn't have to pull in plugins for standard (in Pecan) things 2) Pecan is built for high traffic, where Flask is aimed at much smaller projects 3) Already used by other OpenStack projects, so common patterns can be reused as oslo libs Of course, the Flask community seems larger (though the average flask project seems pretty small). I'm not sure what determines production readiness, but it seems to me like Fuel developers fall more in Pecan's target audience than in Flask's. My $0.02, Ryan -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
Michael, we already solved all issues I described, and I just don't want to solve them once again after moving to another framework. Also, I think, nothing of these wishes contradicts with good API design. On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck krotsch...@gmail.com wrote: This sounds more like you need to pay off technical debt and clean up your API. Michael On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov nmar...@mirantis.com wrote: Hello all, I actually tried to use Pecan and even created a couple of PoCs, but there due to historical reasons of how our API is organized it will take much more time to implement all workarounds we need to issues Pecan doesn't solve out of the box, like working with non-RESTful URLs, reverse URL lookup, returning custom body in 404 response, wrapping errors to JSON automatically, etc. As far as I see, each OpenStack project implements its own workarounds for these issues, but still it requires much less men and hours for us to move to Flask-Restful instead of Pecan, because all these problems are already solved there. BTW, I know a lot of pretty big projects using Flask (it's the second most popular Web framework after Django in Python Web community), they even have their own hall of fame: http://flask.pocoo.org/community/poweredby/ . On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown rybr...@redhat.com wrote: On 12/02/2014 09:55 AM, Igor Kalnitsky wrote: Hi, Sebastian, Thank you for raising this topic again. [snip] Personally, I'd like to use Flask instead of Pecan, because first one is more production-ready tool and I like its design. But I believe this should be resolved by voting. Thanks, Igor On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi all, [snip explanation+history] Best, Sebastian Given that Pecan is used for other OpenStack projects and has plenty of builtin functionality (REST support, sessions, etc) I'd prefer it for a number of reasons. 1) Wouldn't have to pull in plugins for standard (in Pecan) things 2) Pecan is built for high traffic, where Flask is aimed at much smaller projects 3) Already used by other OpenStack projects, so common patterns can be reused as oslo libs Of course, the Flask community seems larger (though the average flask project seems pretty small). I'm not sure what determines production readiness, but it seems to me like Fuel developers fall more in Pecan's target audience than in Flask's. My $0.02, Ryan -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
