Description of problem: The RDO packages do not currently ship anything related to uwsgi. However, one of the recommended ways of deploying things is using uwsgi. The packages are available in EPEL but adding EPEL and RDO together is problematic.
Some context: - uwsgi is the wsgi server used to test in some OpenStack services upstream (cinder, glance, keystone, nova and barbican at least). - OpenStack Ansible (OSA) is adding support to RDO. - OSA is willing to use the same wsgi server used in services gates jobs. - In RDO we currently ship httpd/mod_wsgi as wsgi server. As of today, it's used by deployment tools as TripleO or Packstack. - gunicorn is also included in RDO Repository (used for barbican and octavia, afaik). - uwsgi exists in Fedora and EPEL repos. - Some fork will be needed to build it in CBS (a first scratch built failed complaining about python34-devel and gloox-devel). Some more investigation is needed to find out what other packages we may need to add to RDO as build and runtime requirements.
Would it be possible to evaluate gunicorn or httpd/mod_wsgi as alternatives to uwsgi in OSA?
I will reach out to the OpenStack ansible team and gather their comments on this.
I'd prefer that we consider gunicorn for such use-cases but if openstack-ansible is committing to support RDO packages, I'm not against shipping uwsgi (probably a trimmed down version though).
In OSA we've implemented uwsgi rather than use apache/mod_wsgi for a number of reasons: a. uwsgi has been adopted by the development community and is therefore broadly tested, used and understood by it b. uwsgi provides great debugging and monitoring options [1] c. uwsgi provides adaptive process spawning, helping to scale in a simple and automated way [2] d. uwsgi provides a fastrouter [3] and SSL support [4], negating the need to make use of a web server for the basic needs of most of the API services e. uwsgi provides interesting ways to auto-scale using emperor [5], broodlord [6] and zerg [7] mode [1] https://www.engagespark.com/blog/deploying-monitoring-python-web-apps-uwsgi/ [2] https://uwsgi-docs.readthedocs.io/en/latest/Cheaper.html [3] http://uwsgi-docs.readthedocs.io/en/latest/Fastrouter.html [4] http://uwsgi-docs.readthedocs.io/en/latest/HTTPS.html [5] http://uwsgi-docs.readthedocs.io/en/latest/Emperor.html [6] http://uwsgi-docs.readthedocs.io/en/latest/Broodlord.html [7] http://uwsgi-docs.readthedocs.io/en/latest/Zerg.html We've been using uwsgi since Pike, so our deployers are accustomed to it, so we'd really rather not change the model. As a community we'd really like to keep our tech debt low by ensuring that our deployments across all platforms are uniform, so having uwsgi in RDO packages would really help us out. It might also give the RDO community some interesting new ways to deploy. ;)
(In reply to Jesse Pretorius from comment #5) > In OSA we've implemented uwsgi rather than use apache/mod_wsgi for a number > of reasons: > > a. uwsgi has been adopted by the development community and is therefore > broadly tested, used and understood by it > b. uwsgi provides great debugging and monitoring options [1] > c. uwsgi provides adaptive process spawning, helping to scale in a simple > and automated way [2] > d. uwsgi provides a fastrouter [3] and SSL support [4], negating the need to > make use of a web server for the basic needs of most of the API services > e. uwsgi provides interesting ways to auto-scale using emperor [5], > broodlord [6] and zerg [7] mode > > [1] > https://www.engagespark.com/blog/deploying-monitoring-python-web-apps-uwsgi/ > [2] https://uwsgi-docs.readthedocs.io/en/latest/Cheaper.html > [3] http://uwsgi-docs.readthedocs.io/en/latest/Fastrouter.html > [4] http://uwsgi-docs.readthedocs.io/en/latest/HTTPS.html > [5] http://uwsgi-docs.readthedocs.io/en/latest/Emperor.html > [6] http://uwsgi-docs.readthedocs.io/en/latest/Broodlord.html > [7] http://uwsgi-docs.readthedocs.io/en/latest/Zerg.html > > We've been using uwsgi since Pike, so our deployers are accustomed to it, so > we'd really rather not change the model. As a community we'd really like to > keep our tech debt low by ensuring that our deployments across all platforms > are uniform, so having uwsgi in RDO packages would really help us out. It > might also give the RDO community some interesting new ways to deploy. ;) Sounds ok to me. I'll investigate what do we need to get it rebuilt in RDO. Could i see the list of uwsgi plugins (rpms) installed in OSA?
From our package lists, it's a short set: uwsgi uwsgi-plugin-python mod_proxy_uwsgi I suspect that may bring in some deps. I'll have to do a build to actually validate the full set, but those are the primary packages. Also, there are things we're not using yet, but are on the roadmap - what'll be the process of including those when we're keen to move forward for them?
I've been able to build uwsgi in RDO applying following patch on top of el7 branch in fedora https://github.com/amoralej/uwsgi-distgit/commit/af16f4be58b5b8376937e582c65d89ce18882094 Haïkel, could you take a look? Scratch build passed in https://cbs.centos.org/koji/taskinfo?taskID=443834 Packages are available in https://cbs.centos.org/koji/taskinfo?taskID=443836 in case someone want to do manual tests before pushing it.
I've created a new patch disabling some more plugins, including java (clojure does not exist in CentOS/RDO), rack and perl (perl-PSGI is not in RDO). Latest scratch build is in https://cbs.centos.org/koji/taskinfo?taskID=443847
"committing to support RDO packages" is the critical part, we need someone to sign up under maintainers: in the initial rdoinfo change adding uwsgi + deps
Could you do any test on the mentioned packages?
Yes, we've started working on implementing testing those. I'll post reviews shortly.
uwsgi was rebuilt in RDO using https://github.com/rdo-common/uwsgi/commit/9059a0ea94d5ba557cbac729ca2e43f28c062cd8 and uwsgi-2.0.16-1.el7 is being used in rocky, stein and train.