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