On Thu, 2023-12-07 at 09:06 +0000, Dmitry Tantsur wrote:
I think we should target gunicorn because it's maintained, supports async/await and plays well (IIRC) with eventlet.
But note that I didn't suggest *discouraging* usage of mod_wsgi, I'd just avoid *encouraging* it :)
Dmitry
Yes, this. There are also a few other of other WSGI server implementation (a quick Google points out Nginx Unit [1] and Granian [2] and I'm sure there are more. Coincidentally, both of these are configured with module paths). On top of this, in light of the eventlet "situation", we'd obviously eventually like to get to a point where we're providing ASGI servers rather than WSGI servers but we are still some distance from that. Cheers, Stephen [1] https://unit.nginx.org/configuration/#configuration-python [2] https://github.com/emmett-framework/granian
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