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
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