Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-30 Thread Sebastian Kalinowski
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

2014-12-30 Thread Nikolay Markov
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-08 Thread Sebastian Kalinowski
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

2014-12-08 Thread Nikolay Markov
 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

2014-12-08 Thread Ryan Petrello
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

2014-12-04 Thread Igor Kalnitsky
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

2014-12-04 Thread Roman Prykhodchenko
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

2014-12-04 Thread Nikolay Markov
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

2014-12-04 Thread Ryan Petrello
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

2014-12-03 Thread Alexander Kislitsky
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

2014-12-03 Thread Ivan Kliuk
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

2014-12-03 Thread Przemyslaw Kaminski
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

2014-12-03 Thread Kamil Sambor
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

2014-12-03 Thread Igor Kalnitsky
 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 Thread Sebastian Kalinowski
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

2014-12-03 Thread Przemyslaw Kaminski
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

2014-12-03 Thread Nikolay Markov
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

2014-12-03 Thread Sebastian Kalinowski
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

2014-12-03 Thread Roman Prykhodchenko
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

2014-12-03 Thread Jay Pipes

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

2014-12-03 Thread Nikolay Markov
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

2014-12-03 Thread Roman Prykhodchenko
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

2014-12-03 Thread Jay Pipes

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

2014-12-03 Thread Nikolay Markov
 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

2014-12-03 Thread Nikolay Markov
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

2014-12-03 Thread Jay Pipes

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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-03 Thread Nikolay Markov
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

2014-12-03 Thread Fox, Kevin M
+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

2014-12-03 Thread Ryan Petrello
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

2014-12-03 Thread Fox, Kevin M
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


Re: [openstack-dev] [Fuel][Nailgun] Web framework

2014-12-02 Thread Igor Kalnitsky
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

2014-12-02 Thread Ryan Brown
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

2014-12-02 Thread Nikolay Markov
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

2014-12-02 Thread Michael Krotscheck
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

2014-12-02 Thread Nikolay Markov
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