I did not split the patches for adding the new method and removing the old wsgi-scripts because I think we should just pull the bandaid off here. It's one of those situations where the distros and/or pip/setuptools are just going to break. We are either going to break people that expect the scripts now or in the future. I also found that the script generated by PBR is not handling the thread lock correctly (pylint complained when I created the wsgi module), so it's even slightly broken now (not that I'm 100% sure it would matter in practice). I lean towards a clear release note saying you need to change your deployment over the confusion of installations/upgrades just suddenly not deploying the scripts due to pip/setuptools updates we don't always have constraints over. Michael On Thu, Dec 7, 2023 at 3:41 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2023-12-06 at 18:13 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 17:44 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 13:05 +0100, 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.
This is my preference also and part of the reason for the original email. Django's quickstart tool ('django startproject') places a 'wsgi.py' file in the root of the project [1], which seems like a good convention to follow. However, given some services (Nova, ...?) expose multiple WSGI servers, we need another layer of nesting.
If we could settle on a pattern of '<service>.wsgi.<server>:application' I imagine we'd meet mostly everyone's needs and keep things easy for deployment tooling.
Stephen
[1] https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/
I have proposed a goal to make this clear and help ensure we deliver a consistent pattern across services.
https://review.opendev.org/c/openstack/governance/+/902807
Stephen
Question for the (deployment tooling-focused) audience: is there any advantage to delaying the removal of the wsgi scripts by a cycle and/or backporting the addition of the '<service>.wsgi' modules to Bobcat? Takashi-san brought this up on the goal doc and I'm wondering if we should refine it to include this.
For context, editable wheels built under recent versions of setuptools/pip will not include these scripts (which is a pressing issue for DevStack) but for now they will still be present in non-editable wheels (using the latest pip (23.3.1), setuptools (69.0.2), and pbr (6.0.0)). I don't know how long this situation will last, however. As such, there's no real _cost_ to keeping things around but things will behave differently depending on your environment which will undoubtedly be a source of confusion.
Stephen
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