On Thu, Jul 26, 2018 at 6: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. Distributions are always going to be behind, this isn't surprising. > > 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] > Reloading Python is always tricky, and `execv()` is what I've seen normally to do this > 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] In most of the Ceph ecosystem we use Pecan, and I did mention this as an alternative when the initial PRs came. I've worked with large CherryPy codebases before and I do see some of your points, but although *I* would prefer something like Pecan being used, I don't see how we could improve on most of the points you bring up > > - 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
