On Tue, 2023-02-21 at 19:17 +0100, Dmitriy Rabotyagov wrote:

I kind of wonder what alternatives we have, except mod_wsgi and gunicorn?

As I'm not sure about easy way to adopt CherryPy (or CherryRoot) for instance.

https://gunicorn.org/ apache mod_wsgi and just using the eventlet webserver are the 3 main ones. gunicorn has native supprot for eventlets by the way althoug it can use gevent too. https://docs.gunicorn.org/en/latest/install.html#async-workers

One of obvious requirements for any replacement would be support of TLS. we dont really use the tls functionality for devstack we genreally do the tls termination with apache today if im not mistaken gunicorn has ssl support too. https://docs.gunicorn.org/en/latest/settings.html#ssl

barbican apprenly already can run in gunicorn so i think that is worth looking at as one replacement as an alternitive to mod_wsgi.

Another tricky thing I can think about is handling chunking properly.

вт, 21 февр. 2023 г., 18:07 Jeremy Stanley <fungi@yuggoth.org>:

...

On 2023-02-22 01:12:05 +0900 (+0900), Takashi Kajinami wrote:

...

I happened to notice that uwsgi announced it's now in maintenance mode. https://github.com/unbit/uwsgi/blame/master/README#L5

Is anybody aware of this ? [...]

It looks like there are some additional details here:

https://github.com/unbit/uwsgi/issues/2407

-- Jeremy Stanley

On 22/02/2023 07:39, Dmitriy Rabotyagov wrote:

Well, uwsgi is being also used in real world deployments as of today since ppl tend to use in production smth that is tested in a best possible way. So if we're switching to smth we should consider needs of real deployments as well. But yeah, gunicorn looks good to me

It would also be helpful to have somewhat of an agreed "standard" for running the WSGI components and then a clear move to that within an OpenStack release or two. Having some services only work via mod_wsgi, some using uwsgi by default and others already making a run to gunicorn creates fragmentation. This worsens with different deployment tooling also keeping configuring something different than the "new default" for a while. I now I am getting a little ahead in the discussion of the problem (?), but I wanted to express my affection to a clearly communicated (also technically) move to something else. If this is not a migration / switch, but the introduction of yet another way of doing things this does not improve the operational quality but makes bug hunting and maintenance harder. After all it should be the service, not the runtime people deeply care about, as long as there is feature parity (e.g. TLS support, interfaces for monitoring, good structured request logging, ...). So "enforcing" a different runtime on folks might be less of an issues than it seems. Regards Christian

I've worked at a handful of places running OpenStack at large scale in production. In many of those cases, we used the built-in service runner (eventlet WSGI in at least some cases) and put an HTTP{s} proxy in front. I agree we should probably consider more commonly used-in-production options; but we shouldn't throw out the existing eventlet wsgi server support without explicit technical reasons. Why do you think it's not a serious option? Thanks, Jay Faulkner Ironic PTL TC Member On Mon, Feb 27, 2023 at 6:49 AM Thomas Goirand <thomas@goirand.fr> wrote:

On 2/21/23 19:34, Sean Mooney wrote:

...

just using the eventlet webserver

This isn't a serious option... :/

Cheers,

Thomas Goirand (zigo)

At very least OpenStack-Ansible does deploy all services, with some exceptions like neutron + ovn or glance+ceph, with uwsgi since Train. So I personally won't suggest anyone using eventlet console script in production for all services, while I assume it should work just fine for most cases. пн, 27 февр. 2023 г., 18:27 Sean Mooney <smooney@redhat.com>:

On Mon, 2023-02-27 at 07:23 -0800, Jay Faulkner wrote:

...

I've worked at a handful of places running OpenStack at large scale in production. In many of those cases, we used the built-in service runner (eventlet WSGI in at least some cases) and put an HTTP{s} proxy in front.

I agree we should probably consider more commonly used-in-production options; but we shouldn't throw out the existing eventlet wsgi server support without explicit technical reasons. Why do you think it's not a serious option? kolla used to default to useing the eventlet services untill a few release ago (victoria). so its a preferctly reasonable thing to do.

with that said i belvie some service removed the console entry point for using eventlet (keystone removed it in newton https://github.com/openstack/keystone/tree/mitaka-eol/keystone/server) and some never supported that configuration (placement started as a generic wsgi app). there was a move away form supporting and shiping eventlet console script it over the years.

nova still provides one but its mostly deprecated at this point although i dong think it is offically.

we do not test it anymore and have not for several years at this point.

i think devstack can technially still deployit with nova-api but its been at least 3 or 4 years since that was used in ci.

again kolla did use it for production usage as recently as victoria and in principal nova-api console script is fit for production use but i am not aware of anyoen deploying it that way since kolla changed to using apache.

...

Thanks, Jay Faulkner Ironic PTL TC Member

On Mon, Feb 27, 2023 at 6:49 AM Thomas Goirand <thomas@goirand.fr>

wrote:

...

...

On 2/21/23 19:34, Sean Mooney wrote:

...

just using the eventlet webserver

This isn't a serious option... :/

Cheers,

Thomas Goirand (zigo)

On Mon, 2023-02-27 at 20:57 +0100, Thomas Goirand wrote:

On 2/27/23 18:24, Sean Mooney wrote:

...

On Mon, 2023-02-27 at 07:23 -0800, Jay Faulkner wrote:

...

I've worked at a handful of places running OpenStack at large scale in production. In many of those cases, we used the built-in service runner (eventlet WSGI in at least some cases) and put an HTTP{s} proxy in front.

I agree we should probably consider more commonly used-in-production options; but we shouldn't throw out the existing eventlet wsgi server support without explicit technical reasons. Why do you think it's not a serious option? kolla used to default to useing the eventlet services untill a few release ago (victoria). so its a preferctly reasonable thing to do.

I don't agree. Using Eventlet as a web server has a huge impact on performace (uwsgi can serve twice the amount of requests). A web server in Python without using the multi-interpreter lib is, in general, a very bad idea. if you use mod_wsgi the number of request is limited by the number of processes.

so the eventlet websever willl actully be more effiect then that in terms of requests per core. you are correc tthat uwsgi is faster but many production deploymetn use mod_wsgi which allows each api process to only server 1 request at a time. so huge impact on performance need a base of comparison. for the recored i prefer uwsgi over most other options but the eventlet websever should not be discounted entirely.

Thomas Goirand (zigo)