On 23/02/2023 12:54, Sean Mooney wrote:

I'm not exactly asking for a standard wsgi server across the service
projects, I'm first inclined to sit down with all the projects team members
and come up with a discussion about the uswsgi support.
anyway, happy to hear the TC is taking the ball.

+1, certainly there first has to be a problem to start tackling it.

well the point of using wsgi is that the server should not matter
we shoudl not have a depency on any of them and you should be able touse any wsgi
complaint implamantion.

so i dont think we shoudl be prescibien a server.

we coudl  try and standarise on which framework we have as we have at least 4 wsgi frameworks
in use to implement the wsgi application.

for what its worth the nova-api console scipt is still a thing if you want to use it with the eventlet
webserver via the oslo server integration hwoever that has been deprecated for a long time.

we try to make sure however that you can bring your own wsgi server and keep our wsgi app portable.

form a PTI point of view it proably would make sense to agree on some that we test and support but we
shoudl not change the generic wsgi apps to only run on one server.

Me asking for a "common" wsgi server to be supported / tested and used as a default was just that -> asking for a common default.
Not ruling out more generic wsgi support of the services and them staying compatible with other wsgi frameworks / runtimes.

But as an operator I would love to have a common runtime shared by all services and which I then can operate and monitor in a more generic way.
Just considering (tuning) configuration options, monitoring capabilities and endpoints, their log format, debugging features, ....
If all services run a little different this is just unnecessary overhead to stay on top of things.

And if there is no clear "default", that is tested and that is configured as a default by the various deployment tooling every installation with 5 or 10
openstack services will end up having 3 or 4 different ways the services are doing wsgi. Some do eventlet, others mod_wsgi, some do uwsgi still and others already adopted gunicorn.

And even if they all would "work" with a certain framework, this would then be up to me to identify and to configure them all to.

On 23/02/2023 14:24, Mohammed Naser wrote:

i will have limited upstream time for the next 6 months so i dont want to commit to anything but im
personlaly intereested in seeing if nova/palcement can run under gunicorn well as a uswigi alternitive.
i may even try to add support for that to devstack or other installers if i get time but i cant commit to that.
personally i ahve wanted ot have a lighter weight alternitie to mod_wsgi for years for contaierised openstack

Until you get to Keystone which relies on the service running in front of it for federated auth (like mod_openidc)…

There are plenty of other reverse proxies / webservers doing OIDC via plugin or natively and they all put the OIDC info into HTTP headers.

* OAuth2 proxy - https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview
* Traefik - https://doc.traefik.io/traefik-enterprise/middlewares/oidc/
* NGINX - https://github.com/zmartzone/lua-resty-openidc // https://github.com/zmartzone/ngx_openidc_module
* ...

If Keystone can simply consume the id_token, claims or whatever from a configurable set of headers, this is yet another (hard) dependency removed.

Regards

Christian