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