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