Totally agree with Takashi, In Kolla we use mod_wsgi for all those services that we run as wsgi. While probably we could manage templating wsgi scripts in Kolla-Ansible - I don’t see us doing that on the longer run - especially if that introduces problems not visible in Devstack/other deployment projects. If we switch to Gunicorn and Apache+Gunicorn for Keystone/Horizon SSO - still users that have config overrides for mod_wsgi configs will need to adapt. Michal W dniu pt., 8.12.2023 o 04:35 Takashi Kajinami <kajinamit@oss.nttdata.com> napisał(a):
It may not be a problem for our modules in Puppet OpenStack but cause some problems with surroundings or our operations.
- This causes the circular dependencies between Puppet OpenStack and RDO because - RDO is using Puppet OpenStack for their testing so need the fix for promotion - Puppet OpenStack is using packages which passed testing in RDO so need promotion for fix Mistral already removed the generated wsgi script and replaced it by wsgi.py and we had to handle with making some jobs non-voting and force-move some steps
- Because Ubuntu does not provider packages based on master, we have to test the master branch with UCA bobcat now, so once wsgi script is removed and we adapt to the new wsgi.py, all Ubuntu jobs may not work until UCA Caracal is released and we may loose that test coverage for a few months.
The concern I left in the goal document is more generic one. If we remove the wsgi script immediately then users have to change their wsgi config when they upgrade their deployment from A/B to Caracal. Previously people could upgrade packages first without any config change and then adjust config (eg. replacing a deprecated parameter) but now they have to make sure they make the configuration change at the right timing. Because Puppet OpenStack does not cover upgrade so it may not be a problem for us, but I'm still unsure if this really works with the all deployment toolings, including the one maintained in OpenStack projects and the others maintained externally (like users' own toolings).
So I may vote for keeping the wsgi script at least one cycle, at Caracal release, with the new wsgi.py and then remove the existing wsgi script at D so that C can be a pivot point for smooth transition unless there is real pains/difficulties with keeping the existing wsgi_script entrypoint.
On 12/7/23 21:51, Dmitriy Rabotyagov wrote:
From OpenStack-Ansible perspective there's none, except potential cross-dependencies.
So it would be really nice to remove wsgi scripts with some time margin after adding modules to prevent circular dependencies from happening on integration tests, so that patches at least for "core" services could land smoothly.
On Thu, Dec 7, 2023, 12:41 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
"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
with 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