Wednesday, 2026-07-15

opendevreviewjaehanbyun proposed openstack/kolla-ansible master: Support OCI digest image references  https://review.opendev.org/c/openstack/kolla-ansible/+/99731902:01
opendevreviewKWAK JOONGKEE proposed openstack/kolla-ansible master: glance: add enable_cinder_backend_privileged for cinder store  https://review.opendev.org/c/openstack/kolla-ansible/+/96123502:40
opendevreviewMichal Nasiadka proposed openstack/kolla-ansible master: neutron: Add kolla-ansible ovn-migration subcommand  https://review.opendev.org/c/openstack/kolla-ansible/+/99609607:02
opendevreviewOwen Jones proposed openstack/kolla-ansible stable/2025.2: Fix nova-compute startup after reprovisioning  https://review.opendev.org/c/openstack/kolla-ansible/+/99720608:23
opendevreviewOwen Jones proposed openstack/kolla-ansible stable/2025.1: Fix nova-compute startup after reprovisioning  https://review.opendev.org/c/openstack/kolla-ansible/+/99720808:24
opendevreviewBertrand Lanson proposed openstack/kolla-ansible master: feat: Nova aggregates for compute hosts  https://review.opendev.org/c/openstack/kolla-ansible/+/98888208:32
opendevreviewMichal Arbet proposed openstack/kolla-ansible master: Centralize service log directory management  https://review.opendev.org/c/openstack/kolla-ansible/+/98985008:38
opendevreviewBartosz Bezak proposed openstack/kayobe-config-dev master: CI: support aarch64 Nova guests  https://review.opendev.org/c/openstack/kayobe-config-dev/+/99228508:45
opendevreviewBartosz Bezak proposed openstack/kayobe master: CI: add Rocky 10 aarch64 jobs  https://review.opendev.org/c/openstack/kayobe/+/99228808:49
opendevreviewRafal Lewandowski proposed openstack/kolla stable/2025.1: Add genisoimage package to nova-compute-ironic  https://review.opendev.org/c/openstack/kolla/+/97034508:50
*** jhorstmann is now known as Guest1345208:54
opendevreviewBartosz Bezak proposed openstack/kolla-ansible master: [DNM] test aarch64  https://review.opendev.org/c/openstack/kolla-ansible/+/99734608:55
opendevreviewRafal Lewandowski proposed openstack/kayobe master: Add support for QoS egress/ingress settings in systemd-networkd  https://review.opendev.org/c/openstack/kayobe/+/99720108:58
opendevreviewBartosz Bezak proposed openstack/kolla-ansible master: [DNM] test aarch64  https://review.opendev.org/c/openstack/kolla-ansible/+/99734609:11
opendevreviewWill Szumski proposed openstack/kayobe master: CI: Workaround regression in python-openstackclient  https://review.opendev.org/c/openstack/kayobe/+/99725309:13
opendevreviewBartosz Bezak proposed openstack/kayobe-config-dev master: CI: support aarch64 Nova guests  https://review.opendev.org/c/openstack/kayobe-config-dev/+/99228509:19
opendevreviewWill Szumski proposed openstack/kayobe master: CI: Workaround regression in python-openstackclient  https://review.opendev.org/c/openstack/kayobe/+/99725309:33
opendevreviewMerged openstack/kolla-ansible stable/2026.1: Fix nova-compute startup after reprovisioning  https://review.opendev.org/c/openstack/kolla-ansible/+/99720509:58
opendevreviewRafal Lewandowski proposed openstack/kayobe master: Add support for QoS egress/ingress settings in systemd-networkd  https://review.opendev.org/c/openstack/kayobe/+/99720110:42
opendevreviewMichal Nasiadka proposed openstack/kolla-ansible master: libvirt: Add role for modular libvirt daemons  https://review.opendev.org/c/openstack/kolla-ansible/+/99736710:57
blanson[m]might not be able to make it to the meeting, lights off in a dc so fun times ahead12:10
mnasiadkablanson[m]: dark alleys in the DC? Isn’t that cool? ;-)12:13
blanson[m]yh logging in to compute nodes with 8 minutes of uptime 12:13
blanson[m]loads of fun 12:13
blanson[m]and of course rabbitmq partitioned itself 12:14
blanson[m]cause he wasn't gonna miss the fun 12:14
opendevreviewMichal Arbet proposed openstack/kolla-ansible stable/2026.1: kolla-toolbox: remove leftover kolla-toolbox.json.j2  https://review.opendev.org/c/openstack/kolla-ansible/+/99738112:19
opendevreviewLukasz Chrustek proposed openstack/kolla-ansible master: Fix mount leak with NFS  https://review.opendev.org/c/openstack/kolla-ansible/+/97577112:37
opendevreviewAlex Welsh proposed openstack/kolla-ansible master: Add openstack cacert to uwsgi env for Glance  https://review.opendev.org/c/openstack/kolla-ansible/+/99664712:38
mnasiadkabbezak frickler kevko mmalchuk gkoper jovial mattcrees dougszu darmach pabloclsn ravlew salmankh amir58118 r-krcek blanson[m] - meeting in 6 minutes12:54
*** damian___ is now known as LukaszCh13:00
fungii'm around for my topic as well13:01
mnasiadka#startmeeting kolla13:02
opendevmeetMeeting started Wed Jul 15 13:02:31 2026 UTC and is due to finish in 60 minutes.  The chair is mnasiadka. Information about MeetBot at http://wiki.debian.org/MeetBot.13:02
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.13:02
opendevmeetThe meeting name has been set to 'kolla'13:02
mnasiadka#topic rollcall13:02
ravlew o/13:02
mnasiadkao/13:02
butjar[mit]0/13:02
fungiahoy!13:02
fprzewozno/13:02
bbezakO/13:02
KurtBo/13:02
owenjoneso/13:03
salmankho/13:04
mnasiadka#topic agenda13:04
mnasiadka* CI status13:05
mnasiadka* Current cycle planning13:05
mnasiadka* Additional agenda (from whiteboard)13:05
mnasiadka* Open discussion13:05
mnasiadka#topic CI status13:05
mnasiadkaNo obvious major breakages, apart the python-openstackclient 10.2.0 fallout with requiring cinder13:05
mnasiadkaBut 10.2.1 is out and in u-c - so should be fine13:06
mnasiadka#topic Current cycle planning13:06
mnasiadkaAnybody wants to fill in on any features needing definition of direction? A thorough review? Anything like that?13:06
mnasiadkaOk then, let’s move to additional agenda then13:08
mnasiadka#topic Additional agenda (from whiteboard)13:08
mnasiadkaLet’s start with fungi13:08
mnasiadka(fungi 2026-07-15): Bridging the Gap Gazpacho Cycle Survey and Metrics Analysis13:08
mnasiadka#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/3POML6PYPDWQNYM5IFB54O4ASXEPK4Z5/ Bridging the Gap Gazpacho Cycle Retrospective Survey Results13:08
mnasiadka#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/CVLQIFEVNNJJ7BJSFZJ4RNZZA7ELQKDS/ Bridging the Gap Gazpacho Cycle Retrospective Metrics Analysis13:08
fungiildiko posted openstack-wide 2026.1 (gazpacho) cycle retrospective contributor/maintainer survey results and metrics to openstack-discuss recently:13:09
fungi[links above]13:09
fungii and the other community managers on the openinfra foundation staff have also been digging into team-specific details and i'm doing a round of outreach similar to past cycles, to go over how things may have changed13:09
fungikolla had 2 maintainers and 0 contributors fill out surveys; additional participants for the next round would, as always, help us draw accurate conclusions13:09
fungiaverage ratings on the maintainer survey questions were medium-high, with the respondents averaging 3 out of 5 on timeliness of maintainer reviews and the contributor documentation being up to date, and 4 out of 5 on everything else13:09
fungithe common contribution challenge selected by both was getting shallow reviews from other maintainers leading to further revisions, though they also mentioned shifting consensus, inattention, nit-picking, scope creep, and external blockers13:09
fungiwhen it came to reviewing, both respondents indicated they had trouble getting change owners to follow up on feedback, but additionally cited incomplete changes missing docs/tests and mismatches with team priorities as further challenges13:09
fungithe maintainers also commented that many contributors seem to not be following the team's documented recommendations when it comes to the changes they submit13:10
fungithe new survey questions about ai tools indicate one respondent was using codex both to assist with their review workflow and write documentation as well as speed up repetitive development, the other said they don't use ai for these tasks13:10
fungias for metrics, active maintainer count held steady in gazpacho, though the number of non-maintainer reviewers fell by 9%; changes opened rose by 16% in gazpacho compared to flamingo and the team closed 91% as many as were opened13:10
fungiwe saw the median time to review more than double while the average fell by a third, suggesting maintainers may have become more disciplined in reviewing which is slowing most response times while not letting as many changes linger13:10
fungian important note about metrics this time: since flamingo we've switched from bitergia to lfx insights as our data source, and while the numbers between them are similar there are some slight differences in how activities are counted13:10
fungibecause of this, we re-ran metrics analyses for previous cycles against the new system in order to make sure we weren't trending numbers from different backends and drawing misleading conclusions due to changing measurement methods13:11
fungianyway, that was a quick dump, i know it's a lot to take in but i didn't want to eat up too much of your meeting, so i'll put this on the agenda again for next week to give everyone time to digest and come up with questions or ideas13:11
fungione thing we're interested in finding out is whether the team implemented any new contributor or reviewer practices over the course of the last cycle, for example techniques that were discussed in the previous round of analyses13:11
fungithough i'm happy to answer any immediate feedback now too if there's time13:11
* fungi wonders if he broke everyone's irc clients13:13
bbezak:)13:14
bbezakthis is useful, thx fungi , will try to digest it13:15
fungiglad i could help!13:15
blanson[m]hello ! can be here in the end sorry to be late 13:15
mnasiadkafungi: I’ve been looking at lfx insights - I was thinking of requesting a ‘kolla’ group that would map to all our repos - is that something I should do - or is there a plan to maybe request that based on the governance repo contents?13:15
fungiit's already in the works. they're supposed to be auto-building repository groups for every team based on our governance data13:16
fungioh, on a related note, gouthamr posted a call for participants in the new contributor experience working group, if anyone's interested in that side of things:13:17
fungi#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/R5SW5H2LWSRKT4QFNI4RABMNGNUXHR25/ Contributor Experience Working Group is looking for members13:17
mnasiadkafungi: thanks, so I’ll wait ;-)13:17
mnasiadkaI’ll wait two more minutes for questions and move on with other topics13:18
fungii'm hoping there will be more questions at the next meeting once everyone has time to mull this stuff over13:19
mnasiadkaMakes sense :)13:19
mnasiadkaI’ll leave that on the whiteboard for next meeting13:19
fungii know it's a lot to take in13:19
opendevreviewDoug Szumski proposed openstack/kolla-ansible master: VAST Manila driver  https://review.opendev.org/c/openstack/kolla-ansible/+/95944013:19
mnasiadkaNext topic13:20
mnasiadkablanson (2026/07/13)13:20
mnasiadkaincreasing neutron rpc workers fixed most of the port creation timeouts we had in CI (if not all). How do we scale that properly for users ?13:20
mnasiadkaWe have encountered this ourselves in production with ovs, once there is sufficient pressure on neutron, workers start "missing" commands and some ports never get created because the creation message is never put into rabbitmq.13:20
mnasiadkaOfficial neutron recommendations are 1 rpc worker per 2 cpu cores (https://docs.openstack.org/neutron/latest/configuration/samples/neutron.html , search "rpc_workers")13:20
mnasiadkaInitial idea was: add floor and ceiling values (like 6 and 32, idk), scale to 1 per 2 cores between these values, cap the bottom portion so that small controllers might still have a decent amount, cap the ceiling so that we don't scale this to infinity in case people have absurdly large controllers13:20
mnasiadkause custom values in CI because it doesn't need to be long-term stable ? biggest problems wqith too many workers is memory starvation long term. 13:20
mnasiadkadocumenting this is probbly a good idea aswell.13:20
mnasiadkablanson[m]: not that I’m trying to divert you from that topic, but did you try raising a bug in Neutron?13:20
blanson[m]we haven't, we assumed it was a scaling issue, but it might be worth doing that13:21
blanson[m]or at least ask 13:21
mnasiadkayeah13:21
mnasiadkaBecause in theory, whatever the pressure is, with even 1 worker it should be slow13:21
blanson[m]I wonder how much pressur tempest puts on the cluster13:22
mnasiadkaBut not failing13:22
blanson[m]for it to take 5+ minutes to create a port 13:22
blanson[m]cause past the "missing mesages", if it takes long enough, everyone just cancels the action and the thing never get created anyway13:23
mnasiadkaTrue, but I don’t think these failures showed up in the past, even after moving to dedicated rpc worker process13:23
mnasiadkaAnyway, I think the values we set probably need some revisit13:24
mnasiadkaNow we choose a minimum value from the set [ number of cpus, 3]13:25
blanson[m]yh, which turns out to hurt even more the cluster that need it ? 13:25
mnasiadkaWhich is probably fine for the CI, but nowhere near fine for production13:25
blanson[m]cause usually one would assume the more core you put on the control plane the more need you'll have for increased rpc_workers count ? 13:26
mnasiadkaAnd we recently see it’s not fine for CI ;)13:26
AlmaMC[m]Does neutron recommend something about that ?13:26
mnasiadkaNumber of RPC worker processes for service. If not specified, the default is equal to half the number of API workers.13:27
mnasiadkaOh no, that’s some old comment13:27
mnasiadka#link https://docs.openstack.org/neutron/latest/configuration/neutron.html#DEFAULT.rpc_workers13:27
mnasiadkaNumber of RPC worker processes for service. If not specified, the default is equal to half the CPU count, never using more than half of the system memory. If set to 0, no RPC worker is launched.13:27
mnasiadkablanson[m]: maybe we need to stop setting this?13:27
blanson[m]that could also work ? 13:28
blanson[m]I wrote the initial idea I had in the comment above 13:28
mnasiadkaSo default to an empty string and check | length > 0 in the config file13:28
mnasiadkaAnd that should work better13:28
mnasiadkaAnd we allow users to override it easily13:28
AlmaMC[m]#link https://docs.openstack.org/neutron/latest/admin/config-wsgi.html#neutron-worker-processes13:28
mnasiadkaAlmaMC[m]: that’s for API13:29
mnasiadkaoh, RPC also13:29
mnasiadkasorry13:29
mnasiadka;-)13:29
AlmaMC[m]:)13:29
AlmaMC[m]"For rpc_workers, there needs to be enough to keep up with incoming events from the various neutron agents. Signs that there are too few can be agent heartbeats arriving late, nova vif bindings timing out on the hypervisors, or rpc message timeout exceptions in agent logs (for example, “broken pipe” errors)."13:29
mnasiadkaIf OVN ML2 plugin is used without any additional agents, neutron requires no worker for RPC message processing. Set both rpc_workers and rpc_state_report_workers to 0, to disable RPC workers.13:29
mnasiadkaThat sounds we need to do some magic calculation if we run additional agents13:30
mnasiadkaI’d say we should do both, default to empty rpc_workers when ML2/OVS or OVN with additional agents or set to 0 if pure OVN13:31
mnasiadkabbezak: any opinions?13:31
blanson[m]empty or 0 yields the same no ? 13:33
KurtBFrom the neutron.conf doc for rpc_workers: Number of RPC worker processes for service. If not specified, the default is equal to half the CPU count, never using more than half of the system memory. If set to 0, no RPC worker is launched.13:34
mnasiadkablanson[m]: as in empty Ansible variable which results in unset - which results in half the CPU count13:34
blanson[m]hm right 13:35
bbezakSeems sane, ovn-agent is not using rpc I assume13:35
blanson[m]cause this one option has a proper 0 handling and doesn't do 0 = default value 13:35
mnasiadkaRight, I posted patches to switch from neutron-ovn-metadata-agent to neutron-ovn-agent13:35
mnasiadkabbezak: https://review.opendev.org/c/openstack/kolla-ansible/+/99607813:36
mnasiadka#link https://review.opendev.org/c/openstack/kolla-ansible/+/99607813:36
mnasiadkablanson[m]: want to work on this further?13:38
blanson[m]your patch ? or rpc_workers ? :D 13:38
mnasiadkarpc_workers :D13:38
blanson[m]I can do a proper patch for rpc_workers with what has been discussed here13:38
mnasiadkaLeave my patch alone for now :)13:38
blanson[m]unset if ovs, 0 if ovn 13:40
blanson[m]bassically ? 13:40
blanson[m]basically*13:40
mnasiadkayes13:42
blanson[m]I'll abandon my DNM test and submit a proper chasnge this week maybe weekend depending on how bad our outage turns out to be 13:42
mnasiadkaSounds pragmatically simple and stupid13:42
mnasiadka;)13:42
mnasiadkaWonder what can possibly go wrong13:42
mnasiadkablanson[m]: thanks13:43
KurtBhttps://docs.openstack.org/neutron/2026.1/admin/config-wsgi.html#neutron-worker-processes   Might the relation to api_workers setting have an impact?13:44
mnasiadkaOk, Vii is not on the meeting - so I’ll leave his topics for next week13:44
mnasiadka#topic Open discussion13:47
mnasiadkaAnybody anything?13:47
fprzewoznYeah13:47
fprzewoznhttps://review.opendev.org/c/openstack/kolla-ansible/+/97577113:47
fprzewoznIt was open some time ago13:48
fprzewoznwe've hit the same issue recently13:48
fprzewoznand found out that the fix was almost working13:48
fprzewoznLukaszCh have uploaded patchset and added description there 13:49
LukaszChYes, Robert was almost there with solution :)13:49
fprzewoznreview would be appreciated13:50
mnasiadkaWell, that makes sense, nested mounts are some drama13:51
blanson[m]yh this seems like a reasonable patch 13:52
mnasiadkaAdded myself to reviewers13:52
blanson[m]I can take a look but at a glance it looks okay 13:52
mnasiadkaAnd RP+113:52
fprzewoznthanks13:52
mnasiadkaOk, anybody anything else?13:55
mnasiadkaOk then, thank you all for coming - see you next week!13:58
mnasiadka#endmeeting13:58
opendevmeetMeeting ended Wed Jul 15 13:58:46 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)13:58
opendevmeetMinutes:        https://meetings.opendev.org/meetings/kolla/2026/kolla.2026-07-15-13.02.html13:58
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/kolla/2026/kolla.2026-07-15-13.02.txt13:58
opendevmeetLog:            https://meetings.opendev.org/meetings/kolla/2026/kolla.2026-07-15-13.02.log.html13:58
mnasiadkablanson[m]: the nova-mnt thing actually reminds me I wanted to write a volume spec validator for nested mounts for kolla_container14:07
blanson[m]yh I'm suprised this even worked 14:08
blanson[m]well it didn't 14:08
blanson[m]but still 14:08
blanson[m]I don't remember having a single successful attempt at doing anything nested mout related 14:08
blanson[m]mnasiadka: like something that'd take every single mount and check they don't nest ? 14:09
mnasiadkayeah14:10
opendevreviewMichal Nasiadka proposed openstack/kolla-ansible master: kolla_container: Validate nested mounts in volumes  https://review.opendev.org/c/openstack/kolla-ansible/+/99740014:19
mnasiadkablanson[m]: let’s see if it fails on a deployment ^^14:19
opendevreviewPaweł Koniszewski proposed openstack/kolla-ansible master: Avoid docker volume in case of shared /var/lib/nova  https://review.opendev.org/c/openstack/kolla-ansible/+/99740114:21
opendevreviewMichal Nasiadka proposed openstack/kolla-ansible master: libvirt: Add role for modular libvirt daemons  https://review.opendev.org/c/openstack/kolla-ansible/+/99736714:31
opendevreviewMichal Arbet proposed openstack/kolla master: Remove creating logdirs in docker images  https://review.opendev.org/c/openstack/kolla/+/98984915:02
opendevreviewDoug Szumski proposed openstack/kolla-ansible master: Support deploying multiple Ironic conductor instances  https://review.opendev.org/c/openstack/kolla-ansible/+/99597716:52
opendevreviewDoug Szumski proposed openstack/kolla-ansible master: Support deploying multiple Ironic conductor instances  https://review.opendev.org/c/openstack/kolla-ansible/+/99597716:56
opendevreviewPaweł Koniszewski proposed openstack/kolla-ansible master: Avoid docker volume in case of shared /var/lib/nova  https://review.opendev.org/c/openstack/kolla-ansible/+/99740118:07
opendevreviewPiotr Milewski proposed openstack/kolla master: Upgrade Prometheus Server to LTS version 3.13.1  https://review.opendev.org/c/openstack/kolla/+/99610818:39
opendevreviewMerged openstack/kayobe master: Adds seed IP to default no-proxy list  https://review.opendev.org/c/openstack/kayobe/+/99220421:09

Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!