On Thu, Jul 26, 2018 at 11:44 AM Sebastian Wagner <swagner@xxxxxxxx> wrote: > > Hey, > > we're using CherryPy as the Dashboard's Python framework. This was IMO > an unfortunate decision, even though it was justifiably back then. There > are multiple fundamental problems with it: > > 1. CherryPy is a rather old framework dating back to 2005. Including > some old artifacts, like "_be_ie_unfriendly" which artificially > increases the response-body to exceed about 512 bytes for IE 5 clients. [0] > > 2. Plus, some distributions are not shipping the current release 13.0. > Instead they're shipping a rather old one 3.5.0. This means, we'll have > to maintain compatibility with this outdated version. Also, keep in mind > that we have to monkey-patch CherryPy 3.5.0, in order to fix it's broken > SSL support. > > 3. CherryPy is no meant to be embedded into another bigger application > as a library: In case of errors, it is exiting the parent process. And > engine-reload is implemented by assembling the program-arguments and > calling ::execv() with the current executable (including some > hand-crafted workarounds for Java program arguments). [1] > > 4. Namespace pollution: CherryPy's standard dispatcher calls a > "default"-method if the URL ends with "/", which makes it hard to use > "default" as a valid path-element. For example, GET > /api/erasure_code_profiles/default was broken. (Granted, we no longer > use the default dispatcher in the dashboard) [2] > > 5. Logging in CherryPy is in my opinion a bit over-engineered. CherryPy > is needlessly wrapping logging-calls into its own configuration scheme [3] > > 6. It uses too many global (per thread) variables: The response status > code and headers are stored in a global variables, which are set in > multiple locations. Meaning you have to write your own abstraction layer > on top of CherryPy in order to make it usable without messing with > global variables all the time. [4] > > 7. With openATTIC, we've learned the lesson "don't fight the framework". > With the new dashboard, we're again fighting the framework by replacing > stock-functionality and using monkey-patching to alter the behavior. > > I wouldn't recommend using CherryPy for future mgr modules. On the other > hand I don't see immediate need for us to take any action right now. > CherryPy will continue to be OK for the dashboard. So, I have no real > "call to action" or concrete suggestion, except for raising awareness. > > If you want to ask, if there are other frameworks, my response would be: > "They're saying Flask, Tornado, Pyramid and Django are good frameworks > nowadays." [5] I don't have strong preferences between the various frameworks, since I've worked with a bunch of them and found that each had its own quirks. The original use of cherrypy in mgr modules came from the desire for its multithreaded server (with a bonus framework built in), rather than any particular affinity for the actual application framework piece. I always expect a certain amount of "build your own layer on top" when building atypical web applications. Frameworks like Django will always require some customisation when you're not building a typical database CRUD app, whereas frameworks like Flask are intentionally minimal and leave a lot of structure up to the application author. Looking at openattic, we have the "nodb" parts that were needed to adapt Django to a database-less application -- a sensible design, but also an example of some necessary "fighting the framework". I have had the same experience in the past when working on similar applications -- the api->model piece is usually somewhat custom, depending on what the models really represent in the system you're managing. IME there are two kinds of framework pain: the kind that you can fix and mostly forget (e.g. monkey patching the SSL bits, writing a wrapper for handling status codes differently) and the kind that continue to impact everyday development. The second kind is the worse kind -- do we have issues like that? John > - Sebastian > > > [0] https://github.com/cherrypy/cherrypy/blob/3eb859/cherrypy/_cperror.py#L558 > > [1] https://github.com/cherrypy/cherrypy/blob/3eb859/cherrypy/process/wspbus.py#L285 and > > https://github.com/cherrypy/cherrypy/blob/3eb859/cherrypy/process/wspbus.py#L382 > > [2] https://github.com/cherrypy/cherrypy/blob/3eb859/cherrypy/_cpdispatch.py#L417 > > [3] https://github.com/cherrypy/cherrypy/blob/3eb859/cherrypy/_cplogging.py#L205 > > [4] https://github.com/ceph/ceph/blob/master/src/pybind/mgr/dashboard/controllers/__init__.py#L713 > > [5] https://twitter.com/gvanrossum/status/955523132026101760 > > > > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
