Hi, On 12/7/23 14:15, smooney@redhat.com wrote:
I think we should target gunicorn because it's maintained, supports async/await and plays well (IIRC) with eventlet.
On Thu, 2023-12-07 at 09:06 +0000, Dmitry Tantsur wrote: the choice of wsgi server is reallly upto the installer/operator but for what its worth gunicorn is what starlingx is useing and its used in several other services like monasca too
https://codesearch.opendev.org/?q=gunicorn&i=nope&literal=nope&files=&excludeFiles=&repos=
so weven without going as far as recommending one approach over the other its important to note that it is possible today to use mod_wsgi, uwsgi or gunicorn with some additional packaging/instlaler work today. we dont necessarily need to recommend one over the other just ensure that we enable the installer/packager/opertor to choose the wsgi server that suits there needs best.
Sure, but it does matter what we document as the primary method. That's what newcomers will try to use, it will be a part of their OpenStack first experience. "Why is a single API service consuming gigabytes of RAM" is not the thing you want them to ask after their first deployment :) Dmitry
But note that I didn't suggest *discouraging* usage of mod_wsgi, I'd just avoid *encouraging* it :)
Dmitry
On 12/7/23 09:29, Takashi Kajinami wrote:
I personally agree that using apache + mod_wsgi causes several pains, (It has caused multiple nightmares with service dependency we attempted to describe in puppet) but at the same time would like to remind you all about the fact that uwsgi is now in maintenance mode.
If we officially discourage usage of mod_wsgi and aim to switch to uwsgi completely, then we have to consider investing in uwsgi as the OpenStack community, or start looking for any appropriate alternatives because uwsgi can be abandoned, IMO.
[1] https://github.com/unbit/uwsgi "Note: The project is in maintenance mode (only bugfixes and updates for new languages apis)"
On 12/7/23 02:05, Michael Johnson wrote:
I agree, looking at the changes Stephen has proposed, this is a good approach.
I also strongly agree with Dmitry Tantsur in that we should not go down a path of encouraging mod_wsgi use.
Michael
On Wed, Dec 6, 2023 at 7:05 AM Tobias Urdin <tobias.urdin@binero.com> wrote:
Hello,
On 6 Dec 2023, at 13:05, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
+1 this, I like this approach overall and should be an easy migration for tooling to adopt.
> From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>: > o/ > > For anyone that hasn't been following along, there are changes coming down the > line in the Python packaging world that look likely to break pbr's > 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then > at some point these auto-generated scripts will no longer end up in 'bin' when > pip installed (as we do with e.g. DevStack). > >> From where I'm standing, we appear to have two options: we can either invest > time in pbr to re-implement this functionality from scratch, or we can drop the > idea of auto-generating wsgi scripts from our packaging tool and instead start > using module paths. Having looked at the former, I suspect it is going to be a > *lot* of work that will require implementing our own PEP-517 compatible build > backend instead of cribbing setuptools' one as we do now. Personally, I don't > think this is a good investment of anyone's time, and it gives us more stuff to > maintain for the many years ahead (Did you know that pbr *still* technically > supports Python 2. Fun story that). As such, I think we should instead look to > the former. > > I've proposed some patches for Nova [1][2], which I am hoping will provide a > blueprint for the other services, and patch for DevStack to enable the new Nova > functionality [3]. As you'll see, these patches are relatively small and > hopefully easy to grok. The biggest downside I see to this approach is that > tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack > will need to start packaging their own wsgi script. This is because mod_wsgi > does not appear to support configuration by module paths. On the flipside, > gunicorn does not support configuration by wsgi script so we get that for free. > > I would like to hear other's opinions on this approach. As this is something > that likely affects all services, I suspect that if there's consensus that this > is the correct way to go, there should probably be a small goal drafted for the > current cycle. In my opinion, it would be good to do the migration consistently: > in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module > and IMO if all projects could adopt the same convention we would make the lives > of our deployment tooling colleagues easier. > > Please do let me know if you have any questions or concerns. > > Cheers, > Stephen > > [1] https://review.opendev.org/c/openstack/nova/+/902687/2 > [2] https://review.opendev.org/c/openstack/nova/+/902688/2 > [3] https://review.opendev.org/c/openstack/devstack/+/902758/1 >