On 07/05/15 19:19 -0500, Dolph Mathews wrote:
   We didn't pick Falcon because Kurt was Marconi's PTL and Falcon's
   maintainer. The main reason it was picked was related to performance
   first[0] and time (We didn't/don't have enough resources to even think
   of porting the API) and at this point, I believe it's not even going
   to be considered anymore in the short future.


I'm just going to pipe up and say that's a terribly shallow reason for choosing
a web framework, and I think it's silly and embarrassing that there's not a
stronger community preference for more mature frameworks. I take that as a sign
that most of our developer community is coming from non-Python backgrounds,
which is fine, but this whole conversation has always felt like a plague
of Not-Invented-Here, which baffles me.

Not sure how to parse your email but, FWIW, the community did what was
necessary to promote Pecan and the team decided to stick with Falcon.

I don't believe performance and good fit for your use-case are shallow
reasons to pick a framework.

Most of the projects are using Pecan and it works very well for them
and I believe, as I mentioned in my previous email, it's the framework
projects should default to.

Flavio

   There were lots of discussions around this, there were POCs and team
   work. I think it's fair to say that the team didn't blindly *ignored*
   what was recommended as the community framework but it picked what
   worked best for the service.

   [0] https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation



           pecan is a wsgi framework written by Dreamhost that eventually
           moved
           itself into stackforge to better enable collaboration with our
           community
           after we settled on it as the API for things moving forward.

           Since the decision that new REST apis should be written in Pecan,
           the
           following projects have adopted it:

           openstack:
           barbican
           ceilometer
           designate
           gnocchi
           ironic
           ironic-python-agent
           kite
           magnum
           storyboard
           tuskar

           stackforge:
           anchor
           blazar
           cerberus
           cloudkitty
           cue
           fuel-ostf
           fuel-provision
           graffiti
           libra
           magnetodb
           monasca-api
           mistral
           octavia
           poppy
           radar
           refstack
           solum
           storyboard
           surveil
           terracotta

           On the other hand, the following use falcon:

           stachtach-quincy
           zaqar



       To me this is a strong indicator that pecan will see more eyes and
       possibly be more open to improvement to meet the general need.


   +1


           That means that for all of the moaning and complaining, there is
           essentially one thing that uses it - the project that was started
           by the
           person who wrote it and has since quit.

           I'm sure it's not perfect - but the code is in stackforge - I'm
           sure we
           can improve it if there is something missing. OTOH - if we're going
           to
           go back down this road, I'd think it would be more useful to maybe
           look
           at flask or something else that has a large following in the python
           community at large to try to reduce the amount of special we are.



       +1


   Please, lets not go back down this road, not yet at least. :)




           But honestly - I think it matters almost not at all, which is why I
           keep
           telling people to just use pecan ... basically, the argument is not
           worth it.


   +1, go with Pecan if your requirements are not like Zaqar's.
   Contribute to Pecan and make it better.

   Flavio

   --
   @flaper87
   Flavio Percoco


--
@flaper87
Flavio Percoco

Attachment: pgpk4hx7XYxDc.pgp
Description: PGP signature

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to