Ah, I copy-pastaed[1] and didn't look close enough that it was different from the file created by PBR. [1] https://review.opendev.org/c/openstack/nova/+/902687/4/nova/wsgi/osapi_compu... Michael On Thu, Dec 7, 2023 at 9:18 AM Clark Boylan <cboylan@sapwetik.org> wrote:
On Thu, Dec 7, 2023, at 9:09 AM, Michael Johnson wrote:
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).
If this is an issue we should probably fix it. That said https://pylint.readthedocs.io/en/latest/user_guide/messages/warning/useless-... appears to be the only lock related message in pylint and PBR is doing what is suggested: https://opendev.org/openstack/pbr/src/branch/master/pbr/packaging.py#L378-L3.... I'm not sure what the problem would be given that.
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 >