<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 23/02/2023 12:54, Sean Mooney wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6ad4de222f870498acff11958b394e229aaf9725.camel@redhat.com">
<blockquote type="cite" style="color: #007cff;">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
</blockquote>
+1, certainly there first has to be a problem to start tackling it.<br>
<br>
<blockquote type="cite"
cite="mid:6ad4de222f870498acff11958b394e229aaf9725.camel@redhat.com">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
Me asking for a "common" wsgi server to be supported / tested and
used as a default was just that -> asking for a common default.<br>
Not ruling out more generic wsgi support of the services and them
staying compatible with other wsgi frameworks / runtimes.<br>
<br>
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.<br>
Just considering (tuning) configuration options, monitoring
capabilities and endpoints, their log format, debugging features,
....<br>
If all services run a little different this is just unnecessary
overhead to stay on top of things.
<p>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 <br>
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.<br>
<br>
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.<br>
<br>
<br>
</p>
<div class="moz-cite-prefix">On 23/02/2023 14:24, Mohammed Naser
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEs876jynWEB3=nNsNgs1fvKJP5dusCtKsvoUmg8kd+UOKYR+g@mail.gmail.com">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">i will have
limited upstream time for the next 6 months so i dont want to
commit to anything but im<br>
personlaly intereested in seeing if nova/palcement can run under
gunicorn well as a uswigi alternitive.<br>
i may even try to add support for that to devstack or other
installers if i get time but i cant commit to that.<br>
personally i ahve wanted ot have a lighter weight alternitie to
mod_wsgi for years for contaierised openstack</blockquote>
<div dir="auto"><br>
</div>
<div dir="auto">Until you get to Keystone which relies on the
service running in front of it for federated auth (like
mod_openidc)…</div>
</blockquote>
<br>
There are plenty of other reverse proxies / webservers doing OIDC
via plugin or natively and they all put the OIDC info into HTTP
headers.<br>
<br>
* OAuth2 proxy -
<a class="moz-txt-link-freetext" href="https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview">https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview</a><br>
* Traefik -
<a class="moz-txt-link-freetext" href="https://doc.traefik.io/traefik-enterprise/middlewares/oidc/">https://doc.traefik.io/traefik-enterprise/middlewares/oidc/</a><br>
* NGINX - <a class="moz-txt-link-freetext" href="https://github.com/zmartzone/lua-resty-openidc">https://github.com/zmartzone/lua-resty-openidc</a> //
<a class="moz-txt-link-freetext" href="https://github.com/zmartzone/ngx_openidc_module">https://github.com/zmartzone/ngx_openidc_module</a><br>
* ...<br>
<br>
<br>
<p>If Keystone can simply consume the id_token, claims or whatever
from a configurable set of headers, this is yet another (hard)
dependency removed.</p>
<p><br>
</p>
<p><br>
</p>
<p>Regards</p>
<p><br>
</p>
<p>Christian<br>
</p>
<pre class="moz-quote-pre" wrap="">
</pre>
<br>
<br>
</body>
</html>