Open Stack

On Thu, Feb 23, 2023 at 7:02 AM Sean Mooney <smooney at 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 at 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 at gmail.com>:
> > > >
> > > >
> > > >
> > > > Le jeu. 23 févr. 2023 à 09:30, Thomas Goirand <zigo at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230223/3731439f/attachment-0001.htm>