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