Open Stack

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
> <rprikhodchenko at mirantis.com> wrote:
> > I’d rather suggest doing in several iteration by replacing several resources by Pecan’s implementations.
> > Doing that in one big patch-set will make reviewing very painful, so some bad things might be not noticed.
> >
> >
> >> On 04 Dec 2014, at 14:01, Igor Kalnitsky <ikalnitsky at mirantis.com> wrote:
> >>
> >> Ok, guys,
> >>
> >> It became obvious that most of us either vote for Pecan or abstain from voting.
> >>
> >> So I propose to stop fighting this battle (Flask vs Pecan) and start
> >> thinking about moving to Pecan. You know, there are many questions
> >> that need to be discussed (such as 'should we change API version' or
> >> 'should be it done iteratively or as one patchset').
> >>
> >> - Igor
> >>
> >> On Wed, Dec 3, 2014 at 7:25 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> >>> Choosing the right instrument for the job in an open source community involves choosing technologies that the community is familiar/comfortable with as well, as it will allow you access to a greater pool of developers.
> >>>
> >>> With that in mind then, I'd add:
> >>> Pro Pecan, blessed by the OpenStack community, con Flask, not.
> >>>
> >>> Kevin
> >>> ________________________________________
> >>> From: Nikolay Markov [nmarkov at 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 <jaypipes at gmail.com> wrote:
> >>>> On 12/03/2014 10:53 AM, Nikolay Markov wrote:
> >>>>>>
> >>>>>> However, the OpenStack community is also about a shared set of tools,
> >>>>>> development methodologies, and common perspectives.
> >>>>>
> >>>>>
> >>>>> I completely agree with you, Jay, but the same principle may be
> >>>>> applied much wider. Why Openstack Community decided to use its own
> >>>>> unstable project instead of existing solution, which is widely used in
> >>>>> Python community? To avoid being a team player? Or, at least, why it's
> >>>>> recommended way even if it doesn't provide the same features other
> >>>>> frameworks have for a long time already? I mean, there is no doubt
> >>>>> everyone would use stable and technically advanced tool, but imposing
> >>>>> everyone to use it by force with a simple hope that it'll become
> >>>>> better from this is usually a bad approach.
> >>>>
> >>>>
> >>>> This conversation was had a long time ago, was thoroughly thought-out and
> >>>> discussed at prior summits and the ML:
> >>>>
> >>>> https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks
> >>>> https://etherpad.openstack.org/p/havana-common-wsgi
> >>>>
> >>>> I think it's unfair to suggest that the OpenStack community decided "to use
> >>>> its own unstable project instead of existing solution".
> >>>>
> >>>>
> >>>> Best,
> >>>> -jay
> >>>>
> >>>> _______________________________________________
> >>>> OpenStack-dev mailing list
> >>>> OpenStack-dev at lists.openstack.org
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Nick Markov
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> 
> 
> -- 
> Best regards,
> Nick Markov
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Ryan Petrello
Senior Developer, DreamHost
ryan.petrello at dreamhost.com