| mnasiadka | tc-members: meeting in ~26 minutes here | 07:34 |
|---|---|---|
| tonyb | mnasiadka: noted | 07:34 |
| * frickler is around, but only for 30mins | 07:55 | |
| mnasiadka | #startmeeting tc | 08:00 |
| opendevmeet | Meeting started Tue Jan 20 08:00:01 2026 UTC and is due to finish in 60 minutes. The chair is mnasiadka. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:00 |
| opendevmeet | The meeting name has been set to 'tc' | 08:00 |
| mnasiadka | Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct. | 08:00 |
| mnasiadka | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 08:00 |
| mnasiadka | #topic Roll Call | 08:00 |
| mnasiadka | O/ | 08:00 |
| gtema | O/ | 08:00 |
| frickler | \o | 08:01 |
| bauzas | o/ | 08:01 |
| tonyb | o/ | 08:01 |
| mnasiadka | courtesy-ping: noonedeadpunk | 08:02 |
| mnasiadka | #topic Last Week's AIs | 08:05 |
| mnasiadka | No action items that need to be checked on, ongoing work is in the tracker | 08:05 |
| mnasiadka | #topic What after uWSGI? | 08:05 |
| mnasiadka | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/XPNDG4BL5M6EYG62MXMZKOQ24ZTNBLZZ/ | 08:05 |
| noonedeadpunk | o/ | 08:06 |
| noonedeadpunk | ooops | 08:06 |
| mnasiadka | Noonedeadpunk:just in time, the thread says openstack-ansible has some concerns around uwsgi :) | 08:06 |
| noonedeadpunk | I frankly don't like idea of gunicorn as a replacement | 08:07 |
| noonedeadpunk | it's missing couple of crucial features | 08:07 |
| mnasiadka | Do you have a written down analysis? | 08:07 |
| noonedeadpunk | well, IIRC it was TLS implementation and routing | 08:07 |
| noonedeadpunk | so you pretty much have to use some web server together with it | 08:08 |
| mnasiadka | Compared to uWSGI HTTP mode that usually just works? | 08:08 |
| noonedeadpunk | yup, and kinda feature-complete from my prespective | 08:08 |
| noonedeadpunk | the only thing, is skyline | 08:08 |
| noonedeadpunk | and fastapi, which requires asgi | 08:09 |
| noonedeadpunk | but if we'd be talking about replacement, I'd really would be thinking about granian | 08:09 |
| noonedeadpunk | despite not being fan of rust, it supports both asgi and wsgi, and seems to be able to just replace uwsgi | 08:10 |
| noonedeadpunk | this is where I was going to do some research for over a year now, but never did | 08:10 |
| noonedeadpunk | #link https://github.com/emmett-framework/granian | 08:10 |
| mnasiadka | Can you reply to the linked thread with your thoughts? | 08:10 |
| frickler | sounds to me like a topic for the PTG, or maybe a popup WG? I don't think we can properly handle this within the TC only | 08:11 |
| noonedeadpunk | ah, and the missing feature of uwsgi is actually http/2 support | 08:11 |
| noonedeadpunk | which is a bottleneck for TLS connections | 08:11 |
| noonedeadpunk | yeah, I will compose an answer for the thread | 08:12 |
| mnasiadka | thanks | 08:12 |
| mnasiadka | I agree with frickler, that probably it would need a popup WG | 08:13 |
| noonedeadpunk | frankly, I don't think it's a TC/OpenStack issue | 08:13 |
| noonedeadpunk | we provide proper wsgi apps, and it's up to users to select the web server | 08:13 |
| noonedeadpunk | (or up to deployment tools) | 08:13 |
| mnasiadka | Yes, but we sort of recommend uWSGI nowadays, due to devstack using it | 08:14 |
| noonedeadpunk | um. devstack != recommendation, imo | 08:14 |
| noonedeadpunk | we should be clear about it and purpose of devstack | 08:14 |
| noonedeadpunk | we want to have a reference and most simplistic implementation for CI tests | 08:14 |
| tonyb | yeah technically it isn't needed but it's appropriate for the TC to set the direction and expectations for users | 08:15 |
| noonedeadpunk | I'd even say it should be a list of things which users may expect to work | 08:15 |
| tonyb | and yeah CI/devstack shouldn't be considered a recommendation but in the absence of anything else they will be | 08:15 |
| noonedeadpunk | as any of these tools would be highly opinionated | 08:15 |
| noonedeadpunk | like "openstack APIs are wsgi-compatible, which can be leveraged with services like gunicorn, uwsgi, granian, etc" | 08:17 |
| mnasiadka | Anyway, feels like it’s up to the deployers/users - but it should be stated what is tested today with devstack, but that’s not a recommendation | 08:17 |
| noonedeadpunk | and that is smth we can come up with as a tc | 08:17 |
| frickler | this might be getting a bit out of scope, but we need a framework where developers can tell deployers "this is how you would run new feature X". currently this is devstack mostly | 08:17 |
| noonedeadpunk | which is kinda wrong approach if you ask me.... | 08:18 |
| noonedeadpunk | imo, devstack is pure mix of CI convenience and reference, which can not be really distinguisherd | 08:19 |
| mnasiadka | Well, all the tests run using devstack, so basically it’s not a misconception to use what is most tested | 08:19 |
| frickler | but what would be a better one? like when you implemented skyline for osa, how did you do that | 08:19 |
| noonedeadpunk | with that I'm pretty sure that devstack configures path-based URIs incorrectly for production deployments | 08:19 |
| mnasiadka | Skyline uses unicorn in it’s documented deployment I think | 08:19 |
| mnasiadka | And that’s what we use in Kolla-Ansible - but personally I have no clue if that’s right or wrong :) | 08:20 |
| noonedeadpunk | unless smth changed last 6m, which I doubt | 08:20 |
| frickler | "documented deployment" = devstack? or just their installation docs? | 08:20 |
| mnasiadka | Their installation docs | 08:21 |
| mnasiadka | But their devstack plugin uses gunicorn | 08:22 |
| noonedeadpunk | gunicorn should not work at all with fastapi? | 08:22 |
| noonedeadpunk | it's just not capable of it? | 08:23 |
| frickler | yeah, that's another option (install docs). sadly for many projects these are wildly incomplete, outdated or both | 08:23 |
| mnasiadka | That is starting to broaden the scope of the issue :) | 08:24 |
| bauzas | this is a problem for deployment projects maybe, but that's not service project problem, right? | 08:25 |
| bauzas | like, nova asks to use a WSGI server, that's it | 08:25 |
| bauzas | but I understand the problem for openstack-ansible, for sure | 08:25 |
| mnasiadka | (And any other deployment projects) | 08:26 |
| bauzas | that's why I wonder whether this is a TC concern, but sure we can discuss it | 08:26 |
| noonedeadpunk | I would count deployment projects out here at all, tbh | 08:26 |
| bauzas | that's actually a cross-deployment project indeed | 08:26 |
| noonedeadpunk | I am most thinking of users who want to do their own thing/manual install/etc | 08:26 |
| bauzas | project issue* | 08:26 |
| noonedeadpunk | and how to express what is the reference, and what is not | 08:26 |
| noonedeadpunk | pretty much just requirements for running the service | 08:27 |
| mnasiadka | I think majority projects docs are focused on uWSGI config and mod_wsgi config | 08:27 |
| noonedeadpunk | and from this prespective, I think that should be install guides... | 08:27 |
| mnasiadka | #link https://docs.openstack.org/glance/latest/admin/apache-httpd.html | 08:27 |
| mnasiadka | Glance says uWSGI or mod_wsgi are recommended :) | 08:27 |
| mnasiadka | Well, even worse - uWSGI only | 08:27 |
| mnasiadka | This document describes the recommended deployment patterns for running Glance with Apache HTTPD with uWSGI. | 08:28 |
| noonedeadpunk | I don't see a problem with this I think.... | 08:28 |
| noonedeadpunk | and also Takashi is right, that uWSGI still kinda maintained | 08:28 |
| mnasiadka | I think the topic has been raised, because people are asking how a project that is ‘’in maintenance mode’’ can be recommended | 08:28 |
| noonedeadpunk | latest tag is 3m ago | 08:28 |
| mnasiadka | (At least I’ve seen such voices from the Scientific SIG community) | 08:29 |
| mnasiadka | Anyway, we’re not going to solve it here | 08:30 |
| * frickler sneaks out quietly, will catch up later | 08:30 | |
| mnasiadka | Outside of TC scope - noonedeadpunk will try to reply to the thread with some of his findings that might be beneficial for other people deploying OpenStack | 08:31 |
| mnasiadka | But since uWSGI is still sort of maintained (but not accepting new features like http/2) - it’s hard to justify any work in that subject | 08:31 |
| mnasiadka | Let’s move on | 08:32 |
| mnasiadka | #topic TC Tracker, PTG Follow up | 08:32 |
| mnasiadka | #link https://etherpad.opendev.org/p/tc-2026.1-tracker | 08:32 |
| mnasiadka | Don’t see any updates in the doc - I don’t think there’s anything to discuss regarding the tracker items | 08:33 |
| mnasiadka | #link https://etherpad.opendev.org/p/oct2025-ptg-os-tc-summary | 08:33 |
| mnasiadka | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/RX3MZE33GEDV5JDHORZKRUKVDP47UMLJ/ | 08:34 |
| mnasiadka | (OS/PTG summary) | 08:34 |
| mnasiadka | oonedeadpunk will propose a community goal for project teams to support Character Set changes newer LTS releases of Mariadb/MySQL. | 08:34 |
| mnasiadka | noonedeadpunk: did you get to that? | 08:34 |
| mnasiadka | Ok then, let’s move on to open discussion | 08:37 |
| noonedeadpunk | well :) | 08:37 |
| noonedeadpunk | I have still that in my TODO list quite high | 08:38 |
| mnasiadka | That’s good! | 08:38 |
| mnasiadka | #topic Open Discussion and Reviews | 08:38 |
| mnasiadka | So - I’m off whole February, so I’m looking for a volunteer for running the meeting on 17th Feb | 08:39 |
| opendevreview | Merged openstack/election master: Add configuration for 2026.2/"H" elections https://review.opendev.org/c/openstack/election/+/970565 | 08:39 |
| mnasiadka | And these are the open reviews from gouthamr’s mail: | 08:40 |
| mnasiadka | Revive os_freezer role for OSA | https://review.opendev.org/c/openstack/governance/+/973364 | 08:41 |
| mnasiadka | Revive os_watcher role for OSA | https://review.opendev.org/c/openstack/governance/+/973385 | 08:41 |
| mnasiadka | Remove rbd-iscsi-client from release management |https://review.opendev.org/c/openstack/governance/+/972316 | 08:41 |
| mnasiadka | Remove barbican-ui from release management | https://review.opendev.org/c/openstack/governance/+/972315 | 08:41 |
| mnasiadka | Move FIPS Compliance goal back to proposed | https://review.opendev.org/c/openstack/governance/+/969145 | 08:41 |
| noonedeadpunk | fwiw, I'm potentially also will be unavailable in February, but that is not yet fully decided | 08:42 |
| mnasiadka | There’s no need to decide right now - I just wanted to call it out | 08:43 |
| mnasiadka | Ok then, I don’t see people having any topics for discussion | 08:43 |
| mnasiadka | I’ll wait another 5 minutes and close the meeting | 08:43 |
| bauzas | - | 08:45 |
| tonyb | nothing from me | 08:46 |
| mnasiadka | Thank you all for coming :) | 08:48 |
| mnasiadka | #endmeeting | 08:48 |
| opendevmeet | Meeting ended Tue Jan 20 08:48:33 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 08:48 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2026/tc.2026-01-20-08.00.html | 08:48 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2026/tc.2026-01-20-08.00.txt | 08:48 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2026/tc.2026-01-20-08.00.log.html | 08:48 |
| fungi | i do find it frightening that the hype market has convinced users that maintained feature-complete software is more of a risk than software that's constantly changing and still being developed | 14:16 |
| fungi | do they use grep? how do they feel about its stability? is grep a risk because it's not getting new features constantly? (hyperbole, there are many grep implementations and some of them do occasionally add new features, but the ones shipped in popular distros are generally stable/unchanging over spans of years) | 14:18 |
| sean-k-mooney | fungi: is that in the context of uwsgi | 14:31 |
| sean-k-mooney | or just in general | 14:31 |
| fungi | in general | 14:32 |
| fungi | but it was brought up during the meeting in the context of uwsgi | 14:32 |
| fungi | "...people are asking how a project that is 'in maintenance mode' can be recommended" | 14:33 |
| fungi | i use an entire operating system made up of software components and utilities most of which could be described as in "maintenance mode" and i think that's a good thing | 14:34 |
| cardoe | fungi: that's definitely something I've noticed as well. | 14:47 |
| cardoe | fungi: but I will say uwsgi being in maint mode is problematic. Only because the Linux kernel APIs are evolving and they've made some funky choices about scheduling and memory choices that aligned with older cgroups v1 choices. Things that have been dead and gone from the kernel for a while. Which can make uWSGI do the wrong thing. | 14:48 |
| cardoe | And when someone proposed a patch that was incorrect it was merged without much of a review and shipped in a release which made things worse. | 14:49 |
| cardoe | So that's where I agree that "maint mode" is bad. | 14:49 |
| fungi | yeah, i wouldn't frame a failure to keep pace with changes in underlying subsystems/protocols/standards as "maintenance mode" personally, that's part of maintaining software | 14:50 |
| fungi | it sounds closer to unmaintained, or at best "on life support" by that description | 14:51 |
| fungi | i guess "maintenance mode" has become a kind of euphemism then | 14:51 |
| fungi | "i'm calling it abandoned without calling it abandoned, because there's one person occasionally answering questions on the mailing list who might get offended by that characterization" | 14:52 |
| clarkb | cardoe: fungi: uwsgi is also slow to add new python version support and it still doesn't compile reliably on arm64 | 15:49 |
| clarkb | the problem is that it really isn't in maintenance mode. It is effectively unmaintained and not keeping up with change around it | 15:50 |
| cardoe | Exactly. | 15:51 |
| fungi | yeah, seems like "maintenance mode" has become a negative term due to being misapplied to nearly-abandoned projects in recent years | 15:52 |
| opendevreview | Merged openstack/governance master: Revive os_watcher role for OSA https://review.opendev.org/c/openstack/governance/+/973385 | 17:09 |
| opendevreview | Merged openstack/governance master: Revive os_freezer role for OSA https://review.opendev.org/c/openstack/governance/+/973364 | 17:11 |
| jjung_ | "reached maturity" ? | 17:23 |
| clarkb | the problem with that in this case is that python internal apis have been changing a lot with upstream efforts to improve python interpreter performance. So tools that build against python like uwsgi need regular maintenance to keep up | 17:24 |
| clarkb | if python also reached maturity and stopped making any updates it would probably be fine | 17:25 |
| fungi | yes, it's hard to stabilize software when the language ecosystem under it keeps shifting. of course that only gets worse with all the newer languages people are tempted to reimplement everything in | 17:30 |
| jjung_ | Well, I've reached maturity. It does not mean I don't change, just that it's not crazy change like baby to adult :-) | 17:31 |
| fungi | i've reached old age, but have never stopped being immature ;) | 17:32 |
| clarkb | right but uwsgi isn't even keeping up wit htaht | 17:32 |
| clarkb | it barely compiles on arm64 for example | 17:32 |
| clarkb | I don't think anyone is asking for fancy new features. More that it compile and work with the most recent python release | 17:33 |
| clarkb | I think building a more generic wsgi interface so that deployers can choose different servers is a good idea. The underlying issue here is that we're so closely tied to uwsgi aiui | 17:38 |
| *** tosky_ is now known as tosky | 21:51 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!