Hi, It could be a great chance to discourage people from using mod_wsgi and use the combination with uWSGI indeed. Not just because mod_wsgi is a bad idea in general, but also because of the impeding (although not soon) switch to asynchronous IO. Dmitry On 12/6/23 13:05, Dmitriy Rabotyagov wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
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