Hi there!
It's been a few Debian release that all OpenStack APIs are served using uwsgi. Unfortunately:
https://github.com/unbit/uwsgi/commit/5838086dd4490b8a55ff58fc0bf0f108caa4e0...
The question is then: - Is continuing to use uwsgi sustainable? - Is there good alternatives?
I do not like at all using Apache mod_wsgi, because restarting Apache would mean restarting all services. So I prefer something standalone.
I have no clue if gunicorn is well suited for the job, and if: - it performs well - it implements the multi-interpreter API (which IMO is mandatory to avoid global interpreter locks...)
Any opinion?
Cheers,
Thomas Goirand (zigo)
On Wed, 22 Feb 2023 at 11:15, Thomas Goirand zigo@debian.org wrote:
I do not like at all using Apache mod_wsgi, because restarting Apache would mean restarting all services. So I prefer something standalone.
One Apache mod_wsgi per service is possible and works fine in Kolla.
Hey,
There's already a thread started here yesterday [1]. To have that said - there's a mod_wsgi-express that can be started like uwsgi and in standalone fashion [2]
[1] https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032345... [2] https://pypi.org/project/mod-wsgi-standalone/
ср, 22 февр. 2023 г. в 11:16, Thomas Goirand zigo@debian.org:
Hi there!
It's been a few Debian release that all OpenStack APIs are served using uwsgi. Unfortunately:
https://github.com/unbit/uwsgi/commit/5838086dd4490b8a55ff58fc0bf0f108caa4e0...
The question is then:
- Is continuing to use uwsgi sustainable?
- Is there good alternatives?
I do not like at all using Apache mod_wsgi, because restarting Apache would mean restarting all services. So I prefer something standalone.
I have no clue if gunicorn is well suited for the job, and if:
- it performs well
- it implements the multi-interpreter API (which IMO is mandatory to
avoid global interpreter locks...)
Any opinion?
Cheers,
Thomas Goirand (zigo)
On Wed, 22 Feb 2023 at 12:58, Dmitriy Rabotyagov noonedeadpunk@gmail.com wrote:
Hey,
There's already a thread started here yesterday [1]. To have that said
- there's a mod_wsgi-express that can be started like uwsgi and in
standalone fashion [2]
[1] https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032345... [2] https://pypi.org/project/mod-wsgi-standalone/
It lets pip download apache httpd2 binaries. There is no "standalone" mod_wsgi.
So what is `mod_wsgi-express start-server wsgi.py --port 8080` then? I mean - yes, it will still use apache libraries, but it does resolve the main issue of restarting apache that causes all services restart.
ср, 22 февр. 2023 г. в 13:12, Radosław Piliszek radoslaw.piliszek@gmail.com:
It lets pip download apache httpd2 binaries. There is no "standalone" mod_wsgi.
On Wed, 22 Feb 2023 at 13:19, Dmitriy Rabotyagov noonedeadpunk@gmail.com wrote:
So what is `mod_wsgi-express start-server wsgi.py --port 8080` then? I mean - yes, it will still use apache libraries, but it does resolve the main issue of restarting apache that causes all services restart.
It will run the httpd daemon, just installed by pip, not the distro's package manager. That's it. It supplies the config to make it quicker to start from scratch. I mean, if the other's goal is to get rid of httpd for some reason (like it being bloated or whatever), then this does not solve that particular problem. ;-)
On 22/02/2023 11:14, Thomas Goirand wrote:
I do not like at all using Apache mod_wsgi, because restarting Apache would mean restarting all services. So I prefer something standalone.
I second this argument.
1) I always thought the standalone mode for individual services was the way to go - depending on which distro and deployment tooling one uses this was either default or an option for some (most) services.
2) Being able to switch the webserver to something other than Apache with no dependency to mod_wsgi is nice. Like when running on Kubernetes and using NGINX or whatever to do the reverse proxying.
Regards
Christian
On Wed, 2023-02-22 at 13:18 +0100, Christian Rohmann wrote:
On 22/02/2023 11:14, Thomas Goirand wrote:
I do not like at all using Apache mod_wsgi, because restarting Apache would mean restarting all services. So I prefer something standalone.
I second this argument.
- I always thought the standalone mode for individual services was the
way to go - depending on which distro and deployment tooling one uses this was either default or an option for some (most) services.
- Being able to switch the webserver to something other than Apache
with no dependency to mod_wsgi is nice. Like when running on Kubernetes and using NGINX or whatever to do the reverse proxying.
i think of the option grunicorn is the closet to what uwsig provided and it also support pastedeploy.
lokiing at the monasca logs you can just run it like this
gunicorn -k eventlet --worker-connections=2000 --backlog=1000 --paste /etc/monasca/api-config.ini
https://opendev.org/openstack/monasca-api/src/branch/master/README.rst#L48
im not sure it woudl work out of the box with https://github.com/openstack/nova/blob/master/etc/nova/api-paste.ini the same way but i think ti woudl be doable
looking at starlingx they are already using it https://opendev.org/starlingx/upstream/src/branch/master/openstack/python-ho...
as is skyline and bifrost at least for susitools for testing.
its also used in octavia and ironic have an example https://opendev.org/openstack/ironic/src/branch/master/doc/source/install/in...
gunicorn -b 0.0.0.0:6385 'ironic.api.wsgi:initialize_wsgi_app(argv=[])'
so i think while its not a exact drop in replacme form a cli perspective it could be used with most of the service today. we woudl have to test it but placement for example is ment to be deployable with nginx and gunicorn we jsut dont test that.
Regards
Christian
Just a couple of thoughts on this,
mod_wsgi has had memory and shared library issues historically and also seems to have limited development support[1].
The Octavia API uses uwsgi, like most OpenStack APIs.
In the Octavia amphora images we have been using gunicorn since 2016. This was done to limit the footprint of the service VMs. In my opinion it has worked out well for the project. I hope we seriously consider it if we decide to replace uwsgi.
Michael
[1] https://modwsgi.readthedocs.io/en/master/project-status.html
On Wed, Feb 22, 2023 at 5:01 AM Sean Mooney smooney@redhat.com wrote:
On Wed, 2023-02-22 at 13:18 +0100, Christian Rohmann wrote:
On 22/02/2023 11:14, Thomas Goirand wrote:
I do not like at all using Apache mod_wsgi, because restarting Apache would mean restarting all services. So I prefer something standalone.
I second this argument.
- I always thought the standalone mode for individual services was the
way to go - depending on which distro and deployment tooling one uses this was either default or an option for some (most) services.
- Being able to switch the webserver to something other than Apache
with no dependency to mod_wsgi is nice. Like when running on Kubernetes and using NGINX or whatever to do the reverse proxying.
i think of the option grunicorn is the closet to what uwsig provided and it also support pastedeploy.
lokiing at the monasca logs you can just run it like this
gunicorn -k eventlet --worker-connections=2000 --backlog=1000 --paste /etc/monasca/api-config.ini
https://opendev.org/openstack/monasca-api/src/branch/master/README.rst#L48
im not sure it woudl work out of the box with https://github.com/openstack/nova/blob/master/etc/nova/api-paste.ini the same way but i think ti woudl be doable
looking at starlingx they are already using it https://opendev.org/starlingx/upstream/src/branch/master/openstack/python-ho...
as is skyline and bifrost at least for susitools for testing.
its also used in octavia and ironic have an example https://opendev.org/openstack/ironic/src/branch/master/doc/source/install/in...
gunicorn -b 0.0.0.0:6385 'ironic.api.wsgi:initialize_wsgi_app(argv=[])'
so i think while its not a exact drop in replacme form a cli perspective it could be used with most of the service today. we woudl have to test it but placement for example is ment to be deployable with nginx and gunicorn we jsut dont test that.
Regards
Christian
On Wed, 22 Feb 2023 11:14:24 +0100 Thomas Goirand zigo@debian.org wrote:
It's been a few Debian release that all OpenStack APIs are served using uwsgi. Unfortunately:
Swift uses eventlet, doesn't it?
-- Pete
On Wed, Feb 22, 2023 at 2:03 PM Pete Zaitcev zaitcev@redhat.com wrote:
On Wed, 22 Feb 2023 11:14:24 +0100 Thomas Goirand zigo@debian.org wrote:
It's been a few Debian release that all OpenStack APIs are served using uwsgi. Unfortunately:
Swift uses eventlet, doesn't it?
Anything using oslo.service wsgi module is using eventlet wsgi support. This is what Ironic uses throughout.
Whatever solution we come up with, imo, should be developed and exposed via that oslo.service interface for easy adoption.
-- Jay Faulkner Ironic PTL TC Member
On 2/22/23 22:55, Pete Zaitcev wrote:
On Wed, 22 Feb 2023 11:14:24 +0100 Thomas Goirand zigo@debian.org wrote:
It's been a few Debian release that all OpenStack APIs are served using uwsgi. Unfortunately:
Swift uses eventlet, doesn't it?
-- Pete
Yeah. We tried hard to make both Swift and Glance use uwsgi, but these services simply fail in very subtle ways. It's not obvious that they fail at first, but they really do. I very much believe this is a defect in both projects, and that they should invest time working on this.
Anyways, for the time being, I believe I'll continue using uwsgi for as long as the project is still in maintenance mode. Uwsgi is by far the best, as much as I can tell.
Cheers,
Thomas Goirand (zigo)
Le jeu. 23 févr. 2023 à 09:30, Thomas Goirand zigo@debian.org a écrit :
On 2/22/23 22:55, Pete Zaitcev wrote:
On Wed, 22 Feb 2023 11:14:24 +0100 Thomas Goirand zigo@debian.org wrote:
It's been a few Debian release that all OpenStack APIs are served using uwsgi. Unfortunately:
Swift uses eventlet, doesn't it?
-- Pete
Yeah. We tried hard to make both Swift and Glance use uwsgi, but these services simply fail in very subtle ways. It's not obvious that they fail at first, but they really do. I very much believe this is a defect in both projects, and that they should invest time working on this.
Anyways, for the time being, I believe I'll continue using uwsgi for as long as the project is still in maintenance mode. Uwsgi is by far the best, as much as I can tell.
Shouldn't we somehow identify whether DevStack is at risk given our hard dependency on uwsgi and should we as service project teams somehow kick-off some coordinated brainstorming efforts to identify the risks and mitigate them ?
Sounds a goal to me.
Cheers,
Thomas Goirand (zigo)
At the very least I'd say that the wsgi server used in projects should be standardized and be part of PTI. Previous TC meeting was already hot and full of time-consuming topics, so I've added uwsgi topic for the next meeting agenda.
чт, 23 февр. 2023 г. в 10:21, Sylvain Bauza sylvain.bauza@gmail.com:
Le jeu. 23 févr. 2023 à 09:30, Thomas Goirand zigo@debian.org a écrit :
On 2/22/23 22:55, Pete Zaitcev wrote:
On Wed, 22 Feb 2023 11:14:24 +0100 Thomas Goirand zigo@debian.org wrote:
It's been a few Debian release that all OpenStack APIs are served using uwsgi. Unfortunately:
Swift uses eventlet, doesn't it?
-- Pete
Yeah. We tried hard to make both Swift and Glance use uwsgi, but these services simply fail in very subtle ways. It's not obvious that they fail at first, but they really do. I very much believe this is a defect in both projects, and that they should invest time working on this.
Anyways, for the time being, I believe I'll continue using uwsgi for as long as the project is still in maintenance mode. Uwsgi is by far the best, as much as I can tell.
Shouldn't we somehow identify whether DevStack is at risk given our hard dependency on uwsgi and should we as service project teams somehow kick-off some coordinated brainstorming efforts to identify the risks and mitigate them ?
Sounds a goal to me.
Cheers,
Thomas Goirand (zigo)
Le jeu. 23 févr. 2023 à 11:04, Dmitriy Rabotyagov noonedeadpunk@gmail.com a écrit :
At the very least I'd say that the wsgi server used in projects should be standardized and be part of PTI. Previous TC meeting was already hot and full of time-consuming topics, so I've added uwsgi topic for the next meeting agenda.
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.
чт, 23 февр. 2023 г. в 10:21, Sylvain Bauza sylvain.bauza@gmail.com:
Le jeu. 23 févr. 2023 à 09:30, Thomas Goirand zigo@debian.org a écrit
:
On 2/22/23 22:55, Pete Zaitcev wrote:
On Wed, 22 Feb 2023 11:14:24 +0100 Thomas Goirand zigo@debian.org wrote:
It's been a few Debian release that all OpenStack APIs are served
using
uwsgi. Unfortunately:
Swift uses eventlet, doesn't it?
-- Pete
Yeah. We tried hard to make both Swift and Glance use uwsgi, but these services simply fail in very subtle ways. It's not obvious that they fail at first, but they really do. I very much believe this is a defect in both projects, and that they should invest time working on this.
Anyways, for the time being, I believe I'll continue using uwsgi for as long as the project is still in maintenance mode. Uwsgi is by far the best, as much as I can tell.
Shouldn't we somehow identify whether DevStack is at risk given our hard
dependency on uwsgi and should we as service project teams somehow kick-off some coordinated brainstorming efforts to identify the risks and mitigate them ?
Sounds a goal to me.
Cheers,
Thomas Goirand (zigo)
On Thu, 2023-02-23 at 11:21 +0100, Sylvain Bauza wrote:
Le jeu. 23 févr. 2023 à 11:04, Dmitriy Rabotyagov noonedeadpunk@gmail.com a écrit :
At the very least I'd say that the wsgi server used in projects should be standardized and be part of PTI. Previous TC meeting was already hot and full of time-consuming topics, so I've added uwsgi topic for the next meeting agenda.
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.
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.
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 installs and ci where in both cases reducing disk and memory footprint woudl be a benifit.
чт, 23 февр. 2023 г. в 10:21, Sylvain Bauza sylvain.bauza@gmail.com:
Le jeu. 23 févr. 2023 à 09:30, Thomas Goirand zigo@debian.org a écrit
:
On 2/22/23 22:55, Pete Zaitcev wrote:
On Wed, 22 Feb 2023 11:14:24 +0100 Thomas Goirand zigo@debian.org wrote:
It's been a few Debian release that all OpenStack APIs are served
using
uwsgi. Unfortunately:
Swift uses eventlet, doesn't it?
-- Pete
Yeah. We tried hard to make both Swift and Glance use uwsgi, but these services simply fail in very subtle ways. It's not obvious that they fail at first, but they really do. I very much believe this is a defect in both projects, and that they should invest time working on this.
Anyways, for the time being, I believe I'll continue using uwsgi for as long as the project is still in maintenance mode. Uwsgi is by far the best, as much as I can tell.
Shouldn't we somehow identify whether DevStack is at risk given our hard
dependency on uwsgi and should we as service project teams somehow kick-off some coordinated brainstorming efforts to identify the risks and mitigate them ?
Sounds a goal to me.
Cheers,
Thomas Goirand (zigo)
On Thu, Feb 23, 2023 at 7:02 AM Sean Mooney smooney@redhat.com wrote:
On Thu, 2023-02-23 at 11:21 +0100, Sylvain Bauza wrote:
Le jeu. 23 févr. 2023 à 11:04, Dmitriy Rabotyagov <
noonedeadpunk@gmail.com>
a écrit :
At the very least I'd say that the wsgi server used in projects should be standardized and be part of PTI. Previous TC meeting was already hot and full of time-consuming topics, so I've added uwsgi topic for the next meeting agenda.
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.
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.
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)…
installs and ci where in both cases reducing disk and memory footprint woudl be a benifit.
чт, 23 февр. 2023 г. в 10:21, Sylvain Bauza sylvain.bauza@gmail.com:
Le jeu. 23 févr. 2023 à 09:30, Thomas Goirand zigo@debian.org a
écrit
:
On 2/22/23 22:55, Pete Zaitcev wrote:
On Wed, 22 Feb 2023 11:14:24 +0100 Thomas Goirand zigo@debian.org wrote:
> It's been a few Debian release that all OpenStack APIs are
served
using
> uwsgi. Unfortunately:
Swift uses eventlet, doesn't it?
-- Pete
Yeah. We tried hard to make both Swift and Glance use uwsgi, but
these
services simply fail in very subtle ways. It's not obvious that
they
fail at first, but they really do. I very much believe this is a
defect
in both projects, and that they should invest time working on this.
Anyways, for the time being, I believe I'll continue using uwsgi
for as
long as the project is still in maintenance mode. Uwsgi is by far
the
best, as much as I can tell.
Shouldn't we somehow identify whether DevStack is at risk given our
hard
dependency on uwsgi and should we as service project teams somehow
kick-off
some coordinated brainstorming efforts to identify the risks and
mitigate
them ?
Sounds a goal to me.
Cheers,
Thomas Goirand (zigo)
--
Mohammed Naser VEXXHOST, Inc.
Le jeu. 23 févr. 2023 à 12:55, Sean Mooney smooney@redhat.com a écrit :
On Thu, 2023-02-23 at 11:21 +0100, Sylvain Bauza wrote:
Le jeu. 23 févr. 2023 à 11:04, Dmitriy Rabotyagov <
noonedeadpunk@gmail.com>
a écrit :
At the very least I'd say that the wsgi server used in projects should be standardized and be part of PTI. Previous TC meeting was already hot and full of time-consuming topics, so I've added uwsgi topic for the next meeting agenda.
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.
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.
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 installs and ci where in both cases reducing disk and memory footprint woudl be a benifit.
I can give a try for Nova/Placement. TBC, here my point is that I'd appreciate some cross-project discussion (surely during a vPTG if we may do it, or under the umbrella of the TC) about the possibilities we have. Like I said on #openstack-tc channel, I count three of those: - consider uwsgi being no longer maintained isn't a concern. - consider keeping uwsgi as our devstack main wsgi server and put the maintainance burden on our shoulders (we did that in the past with various outcomes) - consider that keeping uswsgi on devstack is nearly unreasonable and identify the potential alternatives with a solig migration plan if so.
That's only once we agree on the direction we may follow that we should define a migration plan and a strong candidate. In the meantime, like I said, I'm OK with pushing a few DNMs for testing gunicorn on nova-api, nova-metadata-api and placement-api services if thay may help the decision-making.
-Sylvain
чт, 23 февр. 2023 г. в 10:21, Sylvain Bauza sylvain.bauza@gmail.com:
Le jeu. 23 févr. 2023 à 09:30, Thomas Goirand zigo@debian.org a
écrit
:
On 2/22/23 22:55, Pete Zaitcev wrote:
On Wed, 22 Feb 2023 11:14:24 +0100 Thomas Goirand zigo@debian.org wrote:
> It's been a few Debian release that all OpenStack APIs are
served
using
> uwsgi. Unfortunately:
Swift uses eventlet, doesn't it?
-- Pete
Yeah. We tried hard to make both Swift and Glance use uwsgi, but
these
services simply fail in very subtle ways. It's not obvious that
they
fail at first, but they really do. I very much believe this is a
defect
in both projects, and that they should invest time working on this.
Anyways, for the time being, I believe I'll continue using uwsgi
for as
long as the project is still in maintenance mode. Uwsgi is by far
the
best, as much as I can tell.
Shouldn't we somehow identify whether DevStack is at risk given our
hard
dependency on uwsgi and should we as service project teams somehow
kick-off
some coordinated brainstorming efforts to identify the risks and
mitigate
them ?
Sounds a goal to me.
Cheers,
Thomas Goirand (zigo)
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 openstackUntil 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
Yeah. We tried hard to make both Swift and Glance use uwsgi, but these services simply fail in very subtle ways. It's not obvious that they fail at first, but they really do. I very much believe this is a defect in both projects, and that they should invest time working on this.
Glance runs under uwsgi in the gate, and it works fine with all the features (like import) enabled. There are still some -standalone jobs that run it by itself as well. If you find issues, be sure to file bugs (and let me know).
--Dan
participants (12)
-
Christian Rohmann
-
Dan Smith
-
Dmitriy Rabotyagov
-
Jay Faulkner
-
Michael Johnson
-
Mohammed Naser
-
Pete Zaitcev
-
Radosław Piliszek
-
Sean Mooney
-
Sylvain Bauza
-
Sylvain Bauza
-
Thomas Goirand