On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang firstname.lastname@example.org wrote:
We are moving to deploy service via WSGI.
There are two recommended ways.
- apache + mod_wsgi
- nginx + uwsgi
later one is more better.
For traditional deployment, it is easy to implement. Use one
uwsgi progress to launch all wsgi services ( nova-api,cinder-api , etc).
Then one nginx process to forward the http require into uwsgi server.
But kolla is running one process in one container. If we use
the recommended solution, we have to use two container to run
nova-api container. and it will generate lots of containers.
like: nginx-nova-api, uwsig-nova-api.
i propose use uwsgi native http mode. Then one uwsgi
container is enough to run nova-api service. Base one the official
doc, if there is no static resource, uWSGI is recommended to use
as a real http server.
So how about this?
I think this is an interesting approach. At the moment, the Puppet
modules currently allow deploying for services using mod_wsgi.
Personally, I don't think that relying on the HTTP support of uWSGI is
very favorable. It is quite difficult to configure and 'get right'
and it leaves a lot to be desired (for example, federated auth relies
on Apache modules which would make this nearly impossible).
Given that the current OpenStack testing infrastructure proxies to
UWSGI, I think it would be best if that approach is taken. This way,
a container (or whatever service) would expose a UWSGI API, which you
can connect whichever web server that you need.
In the case of Kolla, the
httpd container would be similar to what
haproxy is. In the case of Puppet, I can imagine this being
something to be managed by the user (with some helpers in there). I
think it would be interesting to add the tripleo folks on their
opinion here as consumers of the Puppet modules.
OpenStack Development Mailing List (not for usage questions)