Open Stack

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230223/ea4f174f/attachment.htm>