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

[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 :
>
>> 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
>> >  wrote:
>> > > 2014-12-04 14:01 GMT+01:00 Igor Kalnitsky :
>> > >>
>> > >> 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

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

> 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
> >  wrote:
> > > 2014-12-04 14:01 GMT+01:00 Igor Kalnitsky :
> > >>
> > >> 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

[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
>  wrote:
> > 2014-12-04 14:01 GMT+01:00 Igor Kalnitsky :
> >>
> >> 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

[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
 wrote:
> 2014-12-04 14:01 GMT+01:00 Igor Kalnitsky :
>>
>> 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

[Sebastian Kalinowski]

2014-12-04 14:01 GMT+01:00 Igor Kalnitsky :

> 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

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

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

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

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

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

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

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

[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

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

[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

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

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

[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

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

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

[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

[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  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
>  
> 
> 
> P.
> 
> On 12/03/2014 02:03 PM, Sebastian Kalinowski wrote:
>> 
>> 2014-12-03 13:47 GMT+01:00 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.
>> 
>> 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



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

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

> 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

[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
 wrote:
>
> 2014-12-03 13:47 GMT+01:00 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.
>
>
> 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

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


> 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

[Sebastian Kalinowski]

2014-12-03 13:47 GMT+01:00 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.
>

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

[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  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
>  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 
>> 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
>>>  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 
>>> > 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  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
>>> >> >>  wrote:
>>> >> >>> Hi all,
>>> >> >>>
>>> >> >>> [snip explanation+history]
>>> >> >>>
>>> >> >>> Best,
>>> >> >>> Sebastian
>>> >> >
>>> >> > Given that Peca

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

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

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

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

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

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

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

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

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

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

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

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

[Ryan Petrello]

For what it's worth in terms of "production-ready", pecan is mostly just webob
under the hood, and has been used pretty extensively at DreamHost in
high-traffic environments (we use pecan to handle *all* customer signups for
our entire product line at DreamHost).  Not to mention the other major
OpenStack projects that are already making use of it or are in the process of
switching (Ceilometer, Ironic, Neutron)...

On 12/02/14 04:55 PM, 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
>  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

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

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