| opendevreview | Dale Smith proposed openstack/election master: Add Dale Smith candidacy for Adjutant PTL https://review.opendev.org/c/openstack/election/+/957815 | 00:21 |
|---|---|---|
| opendevreview | Dale Smith proposed openstack/election master: Add Dale Smith candidacy for Magnum PTL https://review.opendev.org/c/openstack/election/+/957816 | 00:22 |
| opendevreview | suzhengwei proposed openstack/election master: Add suzhengwei candidacy for Masakari PTL https://review.opendev.org/c/openstack/election/+/957826 | 02:41 |
| opendevreview | Merged openstack/election master: Adding Guillaume Boutry candidacy for Sunbeam https://review.opendev.org/c/openstack/election/+/957726 | 07:19 |
| opendevreview | Merged openstack/election master: [election] Add mrunge candidacy for Telemetry https://review.opendev.org/c/openstack/election/+/957691 | 07:24 |
| opendevreview | Merged openstack/election master: Adding Takashi Kajinami candidacy for Storlets PTL https://review.opendev.org/c/openstack/election/+/957683 | 07:24 |
| opendevreview | Andriy Kurilin proposed openstack/election master: [Rally] Add Andriy Kurilin candidacy https://review.opendev.org/c/openstack/election/+/957852 | 09:14 |
| opendevreview | Rafael Weingartner proposed openstack/election master: Adding Rafael Weingärtner candidacy for Cloudkitty 2026.1 https://review.opendev.org/c/openstack/election/+/957871 | 10:59 |
| opendevreview | Matt Crees proposed openstack/election master: Adding Matt Crees candidacy for Blazar https://review.opendev.org/c/openstack/election/+/957873 | 11:03 |
| opendevreview | Abhishek Kekane proposed openstack/election master: Adding Cyril Roelandt candidacy for Glance PTL 2026.1 https://review.opendev.org/c/openstack/election/+/957880 | 11:57 |
| opendevreview | Abhishek Kekane proposed openstack/election master: Adding Cyril Roelandt candidacy for Glance PTL 2026.1 https://review.opendev.org/c/openstack/election/+/957880 | 12:00 |
| frickler | just being curious, what exactly are the rules regarding vacated TC seats if there are not enough nominations? will the TC simply be smaller or will there an extra election be made in that case? the charta isn't clear to me in this regard | 14:45 |
| fungi | i believe it hasn't been codified. the last time it happened a special election was arranged immediately following the conclusion of the first | 14:47 |
| fungi | and then the tc immediately took action to gradually reduce the number of seats | 14:48 |
| fungi | in order to avoid a repeat occurrence | 14:48 |
| gouthamr | ack ty fungi | 14:52 |
| fungi | it's been a while now, but i think the partial tc also avoided making any binding governance decisions until the remaining seats were filled by the special election | 14:53 |
| opendevreview | Arnaud Morin proposed openstack/election master: Adding Arnaud Morin candidacy for Mistral https://review.opendev.org/c/openstack/election/+/957940 | 15:15 |
| gmaan | frickler: gouthamr: there are multiple options TC can try and that is what we did in past: | 15:35 |
| gmaan | 1. decrease the TC number of seat (initially we used to be 13 members which shrunk to 9) shrinking it further is not an issue but TC workload/incoming requests and community interest both needs to be considered | 15:35 |
| gmaan | 2. find some more volunteer (in case they missed the nomination deadline for some reason) and have re-election for vacant seat or so | 15:36 |
| fungi | right, those are both things the tc has done in years past | 15:36 |
| gmaan | yeah | 15:36 |
| JayF | I emailed the list encouraging folks to run for the TC. I do not have the time or inclination to, but we have to be able to find two folks :/ | 15:52 |
| gouthamr | o/ tc-members: a gentle reminder that our weekly meeting will happen here in ~1 hour | 16:00 |
| gouthamr | ack on the resolution steps; i added a topic to today's meeting in case it comes to that | 16:00 |
| gouthamr | i am expecting last minute nominations | 16:01 |
| gouthamr | ty for the email JayF | 16:05 |
| opendevreview | Christian Berendt proposed openstack/election master: Add Christian Berendt candidacy for TC 2026.1 https://review.opendev.org/c/openstack/election/+/957954 | 16:35 |
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Aug 19 17:00:08 2025 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| opendevmeet | The meeting name has been set to 'tc' | 17:00 |
| slaweq | o/ | 17:00 |
| gouthamr | 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. | 17:00 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 17:00 |
| gouthamr | #topic Roll Call | 17:00 |
| gtema | o/ | 17:00 |
| gmaan | o/ | 17:00 |
| noonedeadpunk | o/ | 17:01 |
| frickler | \o | 17:01 |
| cardoe | o/ | 17:01 |
| mnasiadka | o/ | 17:01 |
| gouthamr | noted absence: b a u z a s | 17:02 |
| spotz[m] | o/ | 17:02 |
| gouthamr | courtesy ping: spotz[m] | 17:02 |
| spotz[m] | Ha! | 17:03 |
| gouthamr | :P | 17:03 |
| gouthamr | hello everyone, welcome! lets get started | 17:03 |
| gouthamr | #topic Last Week's AIs | 17:03 |
| gouthamr | we wanted to follow up on the proposed goal of migrating from WSGI scripts to module paths | 17:04 |
| gouthamr | #link https://governance.openstack.org/tc/goals/proposed/migrate-from-wsgi-scripts-to-module-paths.html | 17:04 |
| gouthamr | stephenfin will be updating us about this; so we'll check on this AI next week | 17:04 |
| gouthamr | we discussed the runtime update for 2026.1, and wanted to continue the discussion with a proposal | 17:05 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/957199 (Define testing runtime for 2026.1 release) | 17:05 |
| gouthamr | could use a few more pairs of eyes | 17:06 |
| gouthamr | we'll discuss more on the ongoing retirement of monasca repos in a bit | 17:06 |
| gouthamr | i do see some more actionable items discussed during our CI discussion last week, we'll catch up on these during the same slot in a bit | 17:07 |
| gouthamr | that's all the AIs i see, was anyone working on anything else? | 17:08 |
| gouthamr | #topic 2026.1 Election update | 17:09 |
| gouthamr | ty for joining us here slaweq ; i had this slot to discuss how things | 17:10 |
| slaweq | sure, no problem | 17:10 |
| slaweq | we are closing nominations tomorrow at 23:45 utc, so far we don't have approved candidates for 20 projects | 17:10 |
| slaweq | Adjutant Barbican Blazar Cloudkitty Cyborg Glance Magnum Manila Masakari Mistral Monasca OpenStackAnsible OpenStack_Charms Quality_Assurance Rally Swift Tacker Trove Venus Vitrage | 17:11 |
| slaweq | but for some of them we have proposals which needs to be reviewd by ianychoi and mostly should be good | 17:11 |
| gouthamr | does math, about ~1 day, 6 hours left | 17:11 |
| fungi | slaweq: see my earlier mention in the election channel, the cyborg nomination just needs to be reviewed again | 17:11 |
| gouthamr | #link https://review.opendev.org/q/project:openstack/election+status:open | 17:11 |
| slaweq | fungi I already gave +2 for the cyborg nomination | 17:12 |
| gouthamr | its quite helpful to see the "nominations_last_days" email, and ty for working with the cyborg contributors through the OIF staff, fungi | 17:12 |
| gouthamr | i posted on several IRC channels and some changes from past PTLs from teams that don't use IRC | 17:13 |
| slaweq | There are 2 patches with -1 currently, one is for Rally PTL, I already commented that Andriy should renew membership | 17:13 |
| opendevreview | Pierre Riteau proposed openstack/election master: Add Pierre Riteau candidacy for Blazar 2026.1 PTL https://review.opendev.org/c/openstack/election/+/957961 | 17:13 |
| gmaan | I will submit for QA today, i meant to yesterday but got distracted | 17:13 |
| slaweq | and for Blazar it is a bit different as it seems that Matt Crees don' have any patches merged to the project in last year | 17:13 |
| slaweq | regarding TC, we have 2 candidates approved now | 17:14 |
| slaweq | and 1 proposal opened today | 17:14 |
| gouthamr | mattcrees had a change in the pipeline, but rpittau seems to be contesting now ^ | 17:14 |
| slaweq | but still missing at least 1 more | 17:14 |
| mnasiadka | gouthamr: priteau not rpittau ;-) (I know it looks nearly the same) | 17:15 |
| gouthamr | oh boy, ty! | 17:15 |
| * gouthamr doesn't want to influence the specific changes... | 17:15 | |
| gouthamr | i was concerned we have many "roadblocks" during this cycle's nomination window | 17:15 |
| priteau | slaweq: we discussed Blazar together (we are colleagues), I will be candidate for this cycle and we will make sure Matt is eligible for the next election. | 17:17 |
| gouthamr | holidays like we've had over the past, this new requirement to renew OIF membership; and i see the OIF web APIs changing underneath us having election officials to go the extra mile | 17:17 |
| slaweq | there is also problem with names in the https://governance.openstack.org/election/ page but this seems to be like that due to what we got from OIF api | 17:17 |
| gmaan | I thought you said rpittau for TC :) though its good idea if rpittau reading.... | 17:17 |
| fungi | summary there is i've just about got a short-term solution worked out with the foundation's webdev contracting firm, should hopefully be corrected later today so we get full names and irc nicks for everyone again | 17:17 |
| slaweq | thx fungi for taking care of this | 17:18 |
| slaweq | that's I think all from my side for elections | 17:18 |
| fungi | just sorry it's taken so long | 17:18 |
| gouthamr | ty fungi.. | 17:18 |
| gouthamr | no problem; its good to air out why things have been different, and that we're chasing resolution | 17:19 |
| ianychoi | (following up to read message thank u for detailed sharing slaweq ) | 17:20 |
| gouthamr | there are still several projects that are seemingly active, but, i feel sad/frustrated that they don't follow through on election procedures or contributors are hard to reach via irc/mailing list | 17:21 |
| gouthamr | i don | 17:21 |
| gouthamr | t know exactly if we need to rectify that somehow | 17:22 |
| gouthamr | i feel like we do - we've seen this play over and over that its getting a bit tiring | 17:23 |
| gouthamr | /endrant | 17:23 |
| cardoe | You're not wrong | 17:23 |
| JayF | I would suggest that implies that some of those projects may no longer be a good fit for our governance model. | 17:24 |
| gmaan | I noticed the communication is main key in every election and there are always late or PTL appointment for many projects | 17:24 |
| gmaan | election officials doing great improvement in that especially slaweq and ianychoi but still projects miss the nomination | 17:25 |
| gouthamr | ^ where are we going wrong there? election schedules are being posted way earlier than we used to, in the past | 17:25 |
| slaweq | I know it is maybe not topic for now, but maybe it is time to rething our model in general, maybe having PTL election is not really needed anymore | 17:25 |
| gmaan | I am not sure how to solve it. | 17:25 |
| gmaan | yeah, I think we are doing more than needed and best but still project maintainers needs to understand the important of leadership role | 17:26 |
| slaweq | and maybe this should be left for team to be organized internally as currently teams are generally smaller and in fact in many cases they "choose" internally one person who will nominate themself for PTL, so election is in most cases just formality | 17:26 |
| gmaan | yeah, that is also true and not a bad idea | 17:26 |
| fungi | while i commend the election officials on their hard work and dedication, i'm disappointed that just as i had feared it's become a new election official responsibility to chase down prospective candidates and hound them until they follow the nomination process | 17:28 |
| slaweq | so IMO we could only have TC elections and left project leadership to be decided by teams internally, but this is just an idea which maybe TC can discuss at some point, not today for sure :) | 17:28 |
| gouthamr | sometimes, the "hand off" from PTL to next-PTL isn't happening - but this exercise might be a sledgehammer to that nail | 17:28 |
| gmaan | but again we need to make sure every project has PTL | 17:28 |
| spotz[m] | When we had multiple candidates elections made sense for sure | 17:28 |
| JayF | I can't help but wonder, if these teams aren't active for elections, why should we assume they'll be responsive for a security issue if one is reported to the VMT? Or that the project in question will be eventlet-migrated? I have trouble seeing the election inactivity in a vacuum. | 17:29 |
| gouthamr | i agree with you, JayF | 17:30 |
| ianychoi | Yeah, i can also comment that competition ratio has been decreasing - like no voting | 17:30 |
| fungi | getting them to follow release processes too | 17:30 |
| JayF | I just suggest whatever solution we find keeps in mind that "no PTL election" will likely have the effect of pushing the effort of finding someone who is responsive onto teams like VMT or release team. | 17:30 |
| fungi | it's become a release manager responsibility to chase down ptls/liaisons to get release stages approved | 17:30 |
| gmaan | we did that in past and retired many such project but still it is every election story that new set of projects in that list | 17:31 |
| fungi | and a vmt member responsibility to repeatedly hound teams to follow up on vulnerability reorts for that matter | 17:31 |
| noonedeadpunk | and it's way worse during summer elections as well | 17:31 |
| spotz[m] | Maybe an alternative term could even fix the problem | 17:31 |
| * noonedeadpunk failed to submit their candidacy so far | 17:31 | |
| slaweq | I am not proposing to not have PTLs at all, I'm just saying that maybe election process is not that much needed these days | 17:31 |
| slaweq | and we actually already have some kind of alternative which is DPL | 17:32 |
| fungi | noonedeadpunk: norrthern hemisphere summer i suppose you mean? ;) | 17:32 |
| fungi | it's winter for half the world right now | 17:32 |
| noonedeadpunk | oh, yes, thanks for correction | 17:32 |
| gouthamr | we created the election directories a while ago, and asked for folks to nominate themselves a couple months ago iirc: | 17:33 |
| gouthamr | https://review.opendev.org/c/openstack/election/+/949554 | 17:33 |
| opendevreview | Ghanshyam proposed openstack/election master: Add Ghanshyam candidacy for QA PTL https://review.opendev.org/c/openstack/election/+/957963 | 17:35 |
| gouthamr | lets let folks ruminate on the implications of this discussion, and open it up to the community via the ML and the upcoming PTG | 17:35 |
| gmaan | ++ | 17:36 |
| noonedeadpunk | Well, doesn;t seem this had any effect | 17:36 |
| gouthamr | yeah, explains the hair pulling on my part :D | 17:36 |
| gouthamr | in other discussions today, folks were catching up on what happens if there are not enough TC candidates | 17:37 |
| ianychoi | And, any suggestions to advertise to renew OIF memberships from election officials? Seems that we are prioritizing discussions for candidates | 17:37 |
| gouthamr | ianychoi: yes, i think its a short term problem, and your comments linking people to the renewal page are helpful and being acted upon | 17:39 |
| frickler | it is also a problem for the electorate I think? like 50% of active contributors will not be allowed to vote (if it comes to elections) | 17:40 |
| fungi | did you compare that to the percentage who were members in the previous cycle? | 17:40 |
| gouthamr | true, do fungi and you want to paraphrase what this has done to the electorate per your current calculations? | 17:40 |
| frickler | I don't have numbers from the previous elections, if I run the script now for tag 0.18.0, I get data based on current membership state | 17:41 |
| spotz[m] | There's one more TC candidate coming | 17:42 |
| frickler | maybe slaweq or ianychoi have concrete data they can make this comparison with | 17:42 |
| fungi | right, we'd need to look at the _all_owners.yaml file an election official might have saved from last election | 17:42 |
| fungi | but for the moment it looks like most of the contributors who were keeping their member status updated previously have probably renewed them. we need to spend a bit more time researching to say how much impact it's had | 17:44 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/election master: Add Dmitriy Rabotyagov candidacy for OpenStack-Ansible https://review.opendev.org/c/openstack/election/+/957965 | 17:44 |
| ianychoi | https://opendev.org/openstack/election/src/branch/master/tools/tc-election-summary.py#L134 helps? | 17:44 |
| slaweq | I don't have any data like that | 17:44 |
| fungi | ianychoi: only if it has a breakdown of how many change owners weren't foundation members | 17:44 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/election master: Add Dmitriy Rabotyagov candidacy for OpenStack-Ansible https://review.opendev.org/c/openstack/election/+/957965 | 17:45 |
| fungi | i have similar data i can check from last cycle but it's for release contributor counts not election cycles, but probably could give us the basic numbers we're looking for | 17:46 |
| spotz[m] | noonedeadpunk: You had me worried! | 17:46 |
| fungi | i'll try to work on that after my meetings | 17:46 |
| noonedeadpunk | spotz[m]: I'd prefer getting some timeout tbh, but well... | 17:46 |
| gouthamr | i have _all_owners.yaml from March 2025 | 17:47 |
| gouthamr | we can chat fungi | 17:47 |
| spotz[m] | Maybe start training someone?:) | 17:47 |
| fungi | gouthamr: perfect | 17:47 |
| gouthamr | spotz[m]: that is honestly a great thing to bring up | 17:47 |
| ianychoi | fungi: thank you. Execution of election official tool may find the number of electorates who can vote but it is not easy to compare who renewed/not renewed OIF | 17:47 |
| gouthamr | we've spent quite a lot of time on this | 17:48 |
| gouthamr | i can add a topic to the next week's meeting to continue this discussion and proceed to the other topics we had today, any objections? | 17:48 |
| * gouthamr going once..twice... | 17:49 | |
| gouthamr | ty ianychoi for joining us, its nearly 3am your time - i don't know if i should just make you some coffee at this point | 17:49 |
| gouthamr | ty slaweq | 17:50 |
| gouthamr | #topic Monasca retirement open questions | 17:50 |
| gouthamr | #link https://etherpad.opendev.org/p/monasca-retirement | 17:50 |
| gouthamr | ^ on this, we need to start merging changes to "empty" out the repositories.. | 17:50 |
| slaweq | thanks for the discussion, I am calling it a day now :) | 17:50 |
| ianychoi | (Thank you all - may drink water first and consider re-sleeping vs. following-up some items :p ) | 17:50 |
| gouthamr | yes, please do! | 17:51 |
| gouthamr | #link https://review.opendev.org/q/hashtag:%22monasca-retirement%22+(status:open%20OR%20status:merged) | 17:51 |
| gmaan | I saw monasca-api one which was still failing | 17:51 |
| gmaan | #link https://review.opendev.org/c/openstack/monasca-api/+/957064 | 17:51 |
| gmaan | something we need to cleanup on unmaintained branches? | 17:51 |
| gouthamr | yes there are a couple of changes that failed CI here because the unmaintained/2023.1 branch depended on a job definition from master (thanks for investigating this, clarkb) | 17:52 |
| frickler | or force-merge the change on master and ignore the branches? | 17:52 |
| fungi | unmaintained branches on retired projects can probably be deleted | 17:52 |
| gmaan | yeah, deleting them is good idea | 17:52 |
| noonedeadpunk | ++ | 17:53 |
| gouthamr | i can check, but i don't think anything merged after those branches were created | 17:53 |
| gouthamr | if there's nothing changed, we can ignore tagging stuff and just proceed with deletion, yeah? | 17:53 |
| fungi | probably a question for elodilles | 17:53 |
| gouthamr | s/those branches/"unmaintained 2023.1 branch" | 17:53 |
| gmaan | yeah, we do not tag/release them anyways | 17:54 |
| fungi | but i expect so | 17:54 |
| fungi | we do tag them when deleting | 17:54 |
| gmaan | oh, EOL | 17:54 |
| fungi | but there's a process elodilles follows | 17:54 |
| fungi | i'd recommend syncing up with him on the details | 17:54 |
| gouthamr | ty fungi; i expected it to be on some doc somewhere, but was unsuccessful finding it | 17:54 |
| gouthamr | will connect with elodilles; and when i have some updates, i'm going to start bugging tc-members to review/merge these open changes | 17:55 |
| gouthamr | this change itself will not pass without all those repos being "empty": https://review.opendev.org/c/openstack/governance/+/953671 | 17:55 |
| gouthamr | ^ does anyone prefer seeing a whole bunch of "Depends-On" in the commit message here? | 17:56 |
| frickler | you'd create an -eol tag via a release patch and then a release team member can run a script that deletes the branches | 17:56 |
| frickler | no, don't add 20 depends, please | 17:56 |
| gouthamr | i thought so :P | 17:56 |
| gmaan | yeah, leghacy script take care of the cleanup we do not need depends-on | 17:56 |
| gmaan | legacy | 17:56 |
| gouthamr | okay, good stuff | 17:57 |
| gouthamr | that's all i had for $topic.. you'll hear about this stuff later | 17:57 |
| gouthamr | fungi: can i defer the legacy/status tagging topic on PyPi to next week? | 17:57 |
| fungi | yes, there's no urgency for that | 17:58 |
| gouthamr | ty | 17:58 |
| gouthamr | since we only have a couple mins | 17:58 |
| gouthamr | #topic Open Discussion | 17:58 |
| fungi | the default anible version update in zuul has resulted in ubunti-bionic nodes no longer being usable unless the jobs are overridden to use ansible 9, but that version won't be available much longer. this has broken most jobs for py27, py36 and py37, though py27 jobs at least may be able to run on newer ubuntu nodes. we also saw one skyline job that had some vars declared in a | 17:58 |
| fungi | way that newer ansible dislikes (and was possibly not working as expected before either, just silently accepted) | 17:58 |
| gouthamr | ^ very nice, was going to ask | 17:58 |
| gouthamr | was the skyline thing a dependency on these older python versions? | 17:59 |
| fungi | no | 17:59 |
| gouthamr | ubuntu bionic then | 17:59 |
| fungi | just vars being declared in a weird/wrong way that older ansible didn't complain about | 17:59 |
| gouthamr | ah | 17:59 |
| clarkb | before we changed it I hda to fix the multinode bridge role to vendor the openvswitch_bridge module because that entire ansible collection is deprecated and no longer included in ansible | 17:59 |
| fungi | impact to maintained openstack branches should be fairly minor and easily correctable, but there were apparently some projects still testing with old python versions (pbr is an extreme case) | 18:00 |
| clarkb | I think that devstack/tempest are the primary users of this role. It would probably be a good idea to rewrite the role to use linux bridges instead of ovs and avoid code that may stop working with ansible in he future | 18:00 |
| clarkb | basically its working for now, but we have no idea for how long. Best would be to replace it with other tools that should avoid problems | 18:00 |
| frickler | predicting future ansible quirks? that's a tough thing to do | 18:00 |
| gouthamr | #link https://forum.ansible.com/t/several-collections-have-been-deprecated-by-the-ansible-network-team/6360 | 18:01 |
| gouthamr | ty for the heads up there and for the fixes | 18:02 |
| gouthamr | s/fixes/bandaids | 18:03 |
| gouthamr | anything else to note for the minutes today? | 18:03 |
| noonedeadpunk | oops. openvswitch.openvswitch is indeed huge | 18:03 |
| clarkb | we only currently use the one module | 18:03 |
| gouthamr | alright, we've run past the hour | 18:05 |
| gouthamr | ty all for joining and the lively discussion | 18:05 |
| gouthamr | #endmeeting | 18:05 |
| opendevmeet | Meeting ended Tue Aug 19 18:05:30 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:05 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2025/tc.2025-08-19-17.00.html | 18:05 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-08-19-17.00.txt | 18:05 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2025/tc.2025-08-19-17.00.log.html | 18:05 |
| cardoe | I'm gonna sit down at some point and rant on the ML. | 18:06 |
| noonedeadpunk | clarkb: it's used outside of zuul quite in some placed | 18:06 |
| cardoe | We've discussed it before about projects shunning contributors. | 18:07 |
| cardoe | And bringing more contributors from downstream companies using OpenStack is something I've wanted to do as part of my TC involvement. | 18:07 |
| cardoe | A number of projects have vocally said "We need people to be involved." | 18:08 |
| frickler | gmaan: clarkb: I was checking whether kolla is using the same multinode role and found that we have what looks like our set of roles which is getting orchestrated here https://opendev.org/openstack/kolla-ansible/src/branch/master/tests/pre.yml#L8-L53 , maybe that can be leveraged for devstack, too | 18:08 |
| mnasiadka | noonedeadpunk: we just still install that using requirements.yml, we removed our reliance on big Ansible package long time ago, we use ansible-core and defined collections | 18:08 |
| noonedeadpunk | cardoe: the problem is. that almost literally any opensource project today needs more people involved | 18:08 |
| cardoe | So I've brought some downstreams and spoke with their managers and leaders saying "look, get your folks involved and it'll be less work for you to constantly patch every time you upgrade and you can stay more current." | 18:08 |
| mnasiadka | it still works, just largely unmaintained | 18:09 |
| noonedeadpunk | you just really need to pick your battles | 18:09 |
| cardoe | noonedeadpunk: My point is I brought the people. | 18:09 |
| noonedeadpunk | mnasiadka: we do exactly same since 2.9 | 18:09 |
| cardoe | And our projects have been as unwelcoming as possible. | 18:09 |
| noonedeadpunk | oh, ok, this part | 18:09 |
| * noonedeadpunk is very welcoming in projects responsible for :) | 18:09 | |
| noonedeadpunk | mnasiadka: though if you've checked the forum, they said CI is failing for 2.18 | 18:10 |
| cardoe | I've had people review patches that have sat there still. | 18:10 |
| cardoe | I've even had a group of 3 different companies agree to converge on one implementation. Write the implementation. Write tests. Write a spec. | 18:11 |
| cardoe | The response was "the cores are too busy with their own work to consider this for this release. maybe next release." | 18:11 |
| noonedeadpunk | mnasiadka: and well, https://github.com/ansible-collections/openvswitch.openvswitch/commit/edf3538ed34198f44ced8b7c3dd4501837a69ea0 | 18:11 |
| cardoe | It's going to be 3 releases now of that answer. | 18:11 |
| noonedeadpunk | so I guess we'd need to look on "replacement" | 18:11 |
| cardoe | So how much am I gonna be able to convince their leadership to give their people time to be involved in the upstream project when the upstream project shuns them? | 18:12 |
| noonedeadpunk | cardoe: it sounds like we're talking about some very specific project? | 18:12 |
| mnasiadka | noonedeadpunk: no comment, I'm not a fan of replacing it by command ;-) | 18:12 |
| cardoe | I mean that's one specific project. | 18:12 |
| noonedeadpunk | mnasiadka: oh yes. But maybe then replace it by forking it and managing together | 18:13 |
| cardoe | But there's another project that has told people that to submit a patch you need to join their bi-weekly meeting, which happened to be in the middle of the night for the developer. | 18:13 |
| mnasiadka | cardoe: I have a feeling you're specially unlucky | 18:13 |
| mnasiadka | noonedeadpunk: might make sense :) | 18:14 |
| noonedeadpunk | cardoe: so the thing here, is generalization. I totally agree with you, that some projects are as unwelcoming as possible, and each time I need to deal with some, I got really very low morale | 18:14 |
| cardoe | mnasiadka: could be | 18:14 |
| noonedeadpunk | as I know that it's gonna end up with toins of time wasted with no result guaranteed | 18:14 |
| cardoe | I don't have a solution. | 18:14 |
| JayF | mnasiadka: honestly, what cardoe describes matches some of the experiences I've seen -- both inside and outside of openstack | 18:15 |
| noonedeadpunk | at the same time, I'd say totally more of half of projects are super welcoming and happy to accept such work | 18:15 |
| cardoe | But I'm highlighting it here. And I'm giving folks a heads up that I'm gonna air this out on the mailing list. | 18:15 |
| noonedeadpunk | the problem is when generalization is applied to "all upstream work: | 18:15 |
| cardoe | noonedeadpunk: the project you were saying I was being specific about is nova btw. | 18:15 |
| noonedeadpunk | actually with nova I hardly had issues tbh... | 18:15 |
| noonedeadpunk | or well, rather then my coding skill to understand how to improve some parts... | 18:16 |
| noonedeadpunk | but also - this is the reason why we have elections | 18:16 |
| cardoe | mnasiadka: noonedeadpunk: My effort is to try to be someone encouraging shy/new/quiet developers to get involved, which would benefit the project by injecting new people into it. | 18:16 |
| noonedeadpunk | as I if you're saying it's been 3 releases - somebody could propose their candidacy for PTL to change things 2 releases ago | 18:17 |
| noonedeadpunk | especially given that it's such collaboration and time and investment... | 18:17 |
| cardoe | You throw around the PTL thing like a big stick. | 18:17 |
| cardoe | But these are new people to the project. | 18:17 |
| gmaan | or do more reviews and become core and help\ | 18:17 |
| cardoe | gmaan: I've had the developers of those patches review over 100+ other patches. | 18:18 |
| mnasiadka | JayF: I've had very bad experiences with some open source projects managed by some companies that make a living out of it, but OpenStack or Kubernetes has been mainly welcoming (unless it's a forgotten by mainly everybody project that has no pulse) | 18:18 |
| gmaan | I think we are not considering the project core bandwidth and "how much they need help" but always think on "how much they can help" | 18:18 |
| noonedeadpunk | but it kinda is? as PTL is leadership role, which not really represents coding skill/maturity | 18:18 |
| cardoe | They attended the last 2 PTGs and brought up the patch series in both of them | 18:18 |
| opendevreview | Ian Y. Choi proposed openstack/election master: docs: clarify OIF renewal requirement https://review.opendev.org/c/openstack/election/+/957967 | 18:18 |
| noonedeadpunk | so if community is unhappy where project is moving, elections is the tool to have effect on that | 18:18 |
| noonedeadpunk | but yeah, I totally understand your prespective | 18:19 |
| cardoe | The existing community is quite happy with the insular nature. The point here is bringing new faces in. | 18:19 |
| gmaan | of they are reviewing then there is no harm to propose them for core. PTL is one good contact to bring this topic that 'what else should be done to become core'. every project has their own criteria/expectation for core, it is very difficult to generalize them with just quantity | 18:20 |
| cardoe | Can't take that role if they haven't landed a patch. ;) | 18:21 |
| gouthamr | this is something the TC can arbitrate too - we can start a discussion in the particular team's meeting/with the PTL.. | 18:21 |
| noonedeadpunk | but I agree that for new people contribution flow might result in a very confusing and dissapointing experience | 18:21 |
| gouthamr | i don't know if is blocking specific contributors, or if the team, like you put it cardoe is happy being insular | 18:21 |
| gouthamr | if its the former, its malicious, and we're very motivated to fix that problem | 18:22 |
| cardoe | I genuinely believe people are strapped for time. | 18:22 |
| gmaan | gouthamr: be very careful on that topic. TC has done this in past and it backfired TC badly and 'project health checks' model was one example where TC interpreted project scope/work/process wrongly and wrote in health tracker wiki about "project x is not working correctly and not merging things or not fair to everyone" | 18:23 |
| cardoe | People find it easier to review other people's work when they're familiar with the names and faces. | 18:23 |
| noonedeadpunk | for sure it's also a trust thing | 18:24 |
| gouthamr | gmaan: ah, i may not be totally familiar but i recall that i wasn't a fan of the TC being read-only judges :) | 18:24 |
| gmaan | TC handover the project leadership to project and we really need to discuss in advance or do more analysis to bring question on their leadership. I am not saying TC should not do that but I am saying it has to be carefully done and after checking all facts/situation. | 18:24 |
| cardoe | Some of the people telling me the community has a problem are names you all know and have followed. | 18:24 |
| cardoe | People that aren't on here anymore or involved. | 18:24 |
| cardoe | That USE OpenStack on a daily basis and lead large orgs around it. | 18:24 |
| cardoe | I'm not advocating for the TC to come in and stomp their feet. | 18:25 |
| cardoe | I'm highlighting that the TC is saying that elections around PTL and communication with projects is problematic. But the same can be said for contributor engagement and involvement. The projects that might play nice with the TC might not play nice with contributors. The projects that might not play nice with the TC might play nice with contributors. | 18:26 |
| cardoe | It all comes back to governance and communications with the projects. | 18:27 |
| cardoe | You can all tell me I'm wrong or unlucky and that's fine. | 18:27 |
| cardoe | But the next time you see a drive by bug report that's outdated because nobody followed up, remember that was a missed opportunity for a contributor. | 18:28 |
| noonedeadpunk | well, it also could be vice versa that contributors being rude to the projects or during discussions, but being nice afterwards on public spaces | 18:28 |
| noonedeadpunk | I'm not saying it's your case, but there's whole spectre of possibilities I've also witnessed | 18:28 |
| noonedeadpunk | But I totally agree with you that we must be frindly and welcoming for new contributors and efforts to improve projectrs | 18:29 |
| noonedeadpunk | and provide all possible support for them | 18:29 |
| gouthamr | > You can all tell me I'm wrong or unlucky and that's fine. | 18:30 |
| gouthamr | no, i think we've seen these patterns. you're articulating this well.. | 18:30 |
| gouthamr | if we need to bubble this up every now and then for ourselves: https://docs.openstack.org/project-team-guide/review-the-openstack-way.html | 18:31 |
| noonedeadpunk | My failure on bringing new faces was usually these faces dissapearing and becoming unresponsive when either it was coming to actually do some implementation or after first quite valid comments on specs | 18:31 |
| cardoe | noonedeadpunk: no doubt. Sometimes people just throw a patch out there and disappear. | 18:31 |
| noonedeadpunk | but we could be working and discussing things for 2 month before that | 18:31 |
| fungi | i | 18:34 |
| cardoe | Since you've questioned my approach, I'll link you to the last time I've advocated for the nova change since I've named them. https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2025-08-05.log.html | 18:34 |
| cardoe | You can search for my name for the two times I brought it up that day. | 18:34 |
| fungi | i'll just say that when we originated the "bridging the gap" research effort, it wasn't based on vague accusations but actual links to changes and other discussion logs where these issues appeared, so we could analyze and come to more concrete conclusions around causes/reasons | 18:35 |
| cardoe | Overall I don't care about the actual change. | 18:36 |
| fungi | i've come to the conclusion that, while it may come across as confrontational, (politely/discretely) looking at actual cases rather than theorizing in the abstract has been far more effective | 18:36 |
| cardoe | My argument to my leadership and to the leadership at other companies has been if you allow your employees a certain about of time to contribute to upstream OpenStack, your upgrade/integration efforts will be easier in the long run. | 18:37 |
| cardoe | I'll give another example then. | 18:37 |
| fungi | the underlying causes for these failed interactions are nuanced, and hard to generalize | 18:37 |
| cardoe | mnaser: brought this up for another project recently where his team has been trying to land patches | 18:38 |
| fungi | we've been spending months and months trying to get to the underlying reasons, which have almost always come down to incomplete communication | 18:38 |
| cardoe | He even brought up the problem to the TC | 18:38 |
| cardoe | Another person that you all know is Matt Van Winkle. He's got a sizeable team working on OpenStack. They carry a bunch of patches. They've given up on attempting to upstream things. | 18:39 |
| cardoe | It's easier to train the AI code bots to be better at rebasing the series on the next release than it is to hope to get a review and a merge. | 18:40 |
| cardoe | Ultimately we can keep denying it cause every time it gets brought up there's a host of reasons why that person is wrong. | 18:42 |
| cardoe | Or we can just say, "Yes as an open source project we can always strive to improve. Whether that improvement be in our code, our docs, or our handling of contributors." | 18:43 |
| cardoe | And to that effect we should be willing to call each other out when we're not at our best. | 18:44 |
| cardoe | Heck I've got a pile of in flight stuff for Ironic. And I'm not getting it finished. The best thing for me to do would be to solicit others that might be interested in pushing it forward and mentoring them. | 18:45 |
| fungi | i'm actually in our meeting where we're going through target recommendations now, with a plan to start working with a few teams initially on possible alignment | 18:45 |
| fungi | so not able to follow this discussion closely but will revisit it after | 18:46 |
| cardoe | fungi: you just made me feel like I'm sitting in on my annual review with leadership. :D | 18:46 |
| fungi | heh, no upshot from the survey responses and metrics analysis and the per-team discussions i've been conducting in recent weeks | 18:47 |
| opendevreview | Merged openstack/election master: Add suzhengwei candidacy for Masakari PTL https://review.opendev.org/c/openstack/election/+/957826 | 19:47 |
| opendevreview | Merged openstack/election master: Add Dale Smith candidacy for Magnum PTL https://review.opendev.org/c/openstack/election/+/957816 | 19:49 |
| opendevreview | Merged openstack/election master: Add Dale Smith candidacy for Adjutant PTL https://review.opendev.org/c/openstack/election/+/957815 | 19:54 |
| opendevreview | Merged openstack/election master: Adding Rafael Weingärtner candidacy for Cloudkitty 2026.1 https://review.opendev.org/c/openstack/election/+/957871 | 19:54 |
| opendevreview | Merged openstack/election master: Adding Cyril Roelandt candidacy for Glance PTL 2026.1 https://review.opendev.org/c/openstack/election/+/957880 | 19:54 |
| opendevreview | Merged openstack/election master: Adding Li Liu candidacy for Cyborg https://review.opendev.org/c/openstack/election/+/957000 | 19:54 |
| opendevreview | Merged openstack/election master: Adding Arnaud Morin candidacy for Mistral https://review.opendev.org/c/openstack/election/+/957940 | 19:54 |
| fungi | so just to recap the beginnings of the btg effort, the tc asked foundation staff if regular check-ins with member organizations could inquire whether they're contributing upstream and, if not, why | 20:11 |
| fungi | this led to occasional responses with references to specific situations and encounters as examples of upstream contribution struggles they faced | 20:11 |
| fungi | several foundation staffers (ildikov, clarkb and me) dug into the interactions one-by-one in order to try and figure out exactly where things went wrong, slowly grouping them by common characteristics | 20:13 |
| fungi | we relied on hanlon's razor to look for accidental explanations rather than intentional maliciousness or conspiratorial ones | 20:14 |
| fungi | after a while of this, we put together a small focus group of known successful contributors to various parts of openstack in order to help us refine our observations | 20:14 |
| fungi | that led to public discussion in forum sessions and on the openstack-discuss mailing list, then to designing and implementing feedback surveys and zeroing in on indicative activity metrics | 20:16 |
| fungi | and more recently team-by-team discussions in cases where there were enough survey responses to have anything to talk about | 20:16 |
| fungi | we're now trying to formulate more concrete recommendations for avoiding common pitfalls, and are going to engage with a handful of teams in initial trials to implement some of these and get further feedback on what's working and what isn't | 20:18 |
| fungi | but it all started from looking at specific reports where we could meaningfully separate out impression vs cause in those particular experiences | 20:20 |
| fungi | because the one thing that basically all of them had in common was that the people attempting to contribute changes and the maintainers of the projects they were trying to contribute in had clearly differing impressions of how the interaction unfolded | 20:21 |
| fungi | at their core, every one could be explained by miscommunication or lack thereof, and divergent expectations which resulted | 20:23 |
| fungi | so we're trying to work on ways that maintainers and contributors can improve the quality of their communications in order to increase satisfaction and efficiency on both sides of these interactions | 20:24 |
| fungi | (and if all this sounds waaay in the weeds with interpersonal psychology, yeah it's not at all what i expected to find myself working on either as a sysadmin and developer) | 20:25 |
| opendevreview | Merged openstack/election master: Add Christian Berendt candidacy for TC 2026.1 https://review.opendev.org/c/openstack/election/+/957954 | 20:39 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: OSSN-0094: Ensuring Volume Safety w/Nova & Watcher https://review.opendev.org/c/openstack/security-doc/+/957812 | 20:42 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: OSSN-0094: Ensuring Volume Safety w/Nova & Watcher https://review.opendev.org/c/openstack/security-doc/+/957812 | 20:54 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: OSSN-0094: Ensuring Volume Safety w/Nova & Watcher https://review.opendev.org/c/openstack/security-doc/+/957812 | 20:59 |
| cardoe | fungi: its a weird thing how that happens right? We wanna just be poking at keyboards and it ends up being interpersonal psychology. | 21:04 |
| JayF | all software is interpersonal | 21:07 |
| JayF | Nothing we do is worth doing if persons don't benefit from it :) | 21:07 |
| JayF | you can never separate the two | 21:07 |
| cardoe | Very valid point. | 21:13 |
| gouthamr | from the interaction you linked, cardoe, "cores shoudl only +2 a spec if they intend to spend time reviewin it" - an arcane process within one of our most popular teams - super well intended because it ensures core reviewers are not burnt out.. but, as a contributor i don't know if i can discover that.. i read through https://docs.openstack.org/nova/latest/contributor/process.html | 21:26 |
| gouthamr | i'll share sean-k-mooney's appreciation of your efforts.. | 21:27 |
| sean-k-mooney | so that process is new | 21:28 |
| sean-k-mooney | and was propsed beacuse fo direct feedback form the latest survay | 21:28 |
| gouthamr | oh | 21:29 |
| sean-k-mooney | i.e. the contibtors survay on how to improve code review | 21:29 |
| sean-k-mooney | the intent is to not over promise by approving specs if we dont think we woudl have time to review them | 21:29 |
| fungi | that's awesome, btw | 21:30 |
| gouthamr | ack, we did have something similar in other teams i think with assigning two core reviewers to shephard a particular change along.. but, core folks were being voluntold by the PTL | 21:30 |
| sean-k-mooney | so we actully have not started applying it yet because that feeback was recived mid way trought hte cycle | 21:30 |
| sean-k-mooney | but its what we plan to dicuss at the next ptg and likely adopt | 21:30 |
| sean-k-mooney | at least to tryit for 2026.1 and see if it helps | 21:31 |
| gouthamr | +1, so would cardoe currently have to find a couple of core reviewers that can help move things along, or would Uggla take care of doing that? | 21:31 |
| sean-k-mooney | this is also why its not in our contiutor docs yet. we have not agreed to adopt that rule yet | 21:31 |
| sean-k-mooney | which revie is this specificly for? | 21:32 |
| sean-k-mooney | Uggla can help but i may be able to if i have context | 21:32 |
| cardoe | I don't want to special case that one thing. | 21:34 |
| cardoe | And likely the opportunity with some of those teams leaders has passed. | 21:34 |
| cardoe | But I was asked to be concrete and name an instance. | 21:35 |
| gouthamr | agreed | 21:35 |
| sean-k-mooney | ack, i know at least oen of the case was "we recheced spec freeze for this cycle" and i had +2'd the spec but none of the other cores wanted to comemit to reviewing | 21:36 |
| gouthamr | i'd love to work with fungi and get the BTG sessions to the TC/PTL meetup at the upcoming PTG | 21:36 |
| sean-k-mooney | so tha twas the trunk metadata feature i think | 21:36 |
| gouthamr | sean-k-mooney: https://review.opendev.org/c/openstack/nova-specs/+/471815 | 21:36 |
| sean-k-mooney | ya that one exactly | 21:36 |
| sean-k-mooney | so that was an old spec that no one showed any instrest in for quite a whiel | 21:37 |
| sean-k-mooney | i reviewd it when cardoe highlghted that they were interested | 21:37 |
| sean-k-mooney | but then it hit spec freeze at milestone 2 | 21:37 |
| cardoe | Well, I highlighted it long after it had been created. | 21:38 |
| sean-k-mooney | right but it had been dicssed years ago | 21:38 |
| sean-k-mooney | ant the orgianl proposes stoped working onit in 2017/2018 | 21:38 |
| sean-k-mooney | that why it was orginally abandoned because no one was askign for it or workign in ot | 21:39 |
| sean-k-mooney | *working on it. | 21:39 |
| sean-k-mooney | wnayway this just aan example so no need to focus to much on the details of that one spec | 21:39 |
| fungi | i think a relatively positive example (on a scale of terrible to not to terrible) is the latest iteration of image encryption getting added to nova. the parties involved hashed it out on the mailing list and i think came to an understanding as to where their expectations didn't match up | 21:41 |
| sean-k-mooney | am i correct in sayign that sometime interset in old idea or even new oens can increase btu its not alwasy clear how to highlight that to project teams and get there attention if your a new contibutor | 21:41 |
| sean-k-mooney | fungi: ya that another godo example where there was a discconect in expections | 21:41 |
| sean-k-mooney | but dan agreed to follwo up | 21:41 |
| sean-k-mooney | form my perspecitve it was nto approved for the relase and not valid to include this cycle | 21:42 |
| sean-k-mooney | but i dint object ot other cores reviewing it | 21:42 |
| sean-k-mooney | i just abstaied and noteed the normal process was nto being followed | 21:42 |
| fungi | some teams requiring specs to be re-submitted and reapproved every cycle while others don't causes some understandable confusion for people working on cross-project feature implementations too | 21:43 |
| sean-k-mooney | in general we dont want to block things on paperwork | 21:43 |
| sean-k-mooney | fungi: ya so for nova that has alwasy been a hard rule | 21:44 |
| sean-k-mooney | but your right not all project require that | 21:44 |
| sean-k-mooney | the intent is pretty obvious at least to me, limit the things the core team has to review coming up to feature freeze | 21:45 |
| sean-k-mooney | so we get the planned work done | 21:45 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/926326 | 21:46 |
| sean-k-mooney | the pach is appvoed by the way but i think it need recheck to merge | 21:46 |
| sean-k-mooney | oh it still has a cinder dep https://review.opendev.org/c/openstack/cinder/+/926298 | 21:46 |
| fungi | yeah, i mean the policy is obvious to me, but may not be apparent (or at least memorable) for infrequent contributors or people working across multiple projects | 21:47 |
| sean-k-mooney | ya cross project owrk is always tricker | 21:47 |
| sean-k-mooney | honsetly alot of it just comes back to comunication which is hard | 21:49 |
| fungi | and i'm not blaming nova folks for that, the fact that the image encryption work has happened in spurts with lengthy lags in contribution hasn't helped matters either. but the positive aspect is that everyone on both sides of that interaction has observed patience and stayed polite | 21:49 |
| JayF | sean-k-mooney: a gross intersection is with things like the ironic driver, where there literally *are not* two nova cores who are really familiar with the code | 21:49 |
| JayF | it sorta means if knowledge is lost outta the core team, that corner of the code could go dark | 21:50 |
| JayF | and that's true for "I don't want to work on this code" opinions, too | 21:50 |
| sean-k-mooney | yep which is the situration with the vmware dirver | 21:50 |
| JayF | I don't wanna make that sound blame-y, there are Ironic pieces I don't review generally | 21:50 |
| sean-k-mooney | being entirly transparent anyoen who really really cared about that driver left the comunity years ago | 21:50 |
| JayF | the difference for the ironic/nova driver is we have openstack-contributing experts in that code; just not many of them are nova cores | 21:50 |
| JayF | I care a lot about the ironic/nova driver fwiw :) | 21:51 |
| sean-k-mooney | well not entirly but at elast form the point of view of cores ro peopel with deep knowladge of it that are around consitently | 21:51 |
| JayF | and I would never say out loud that I've even tested a backported version into older nova with a newer ironic ;) | 21:51 |
| clarkb | fwiw I fairly regularly review code that I'm not super familar with. That is part of the job. You do your best and build an understanding as you go and then if that understanding is as good as it gets you proceed | 21:51 |
| clarkb | this is how you build the necessary background knowledge. If we decided upfront that we can review something due to unfamiliarity I'm not sure opendev would get much done | 21:52 |
| JayF | clarkb: that's true, and I do the same, but I won't +2 code that I'm not willing to debug myself if a bug if filed against it | 21:52 |
| sean-k-mooney | yep i try to do that too to bemome more familar with the areas i dotn touch as often | 21:52 |
| JayF | clarkb: but the sense of "how much I have to understand it" has def. shrunk in the years I've been around | 21:52 |
| clarkb | we have some amazing guard rails in our CI system | 21:52 |
| clarkb | and you can always revert | 21:52 |
| JayF | clarkb: I don't trust Ironic CI to reflect physical hardware, sadly | 21:53 |
| JayF | we cannot anticipate how horrible the implementations are that we will talk to | 21:53 |
| clarkb | no but it should capture the api interface between say ironic and nova | 21:53 |
| JayF | I learn new terrible hardware quirks monthly at this poitn lol | 21:53 |
| JayF | yeah | 21:53 |
| sean-k-mooney | clarkb: yeah... it shoudl alsthough nova and ironci dont alwasy agree on what that itnerface is :) | 21:53 |
| sean-k-mooney | but that i sa difent story | 21:54 |
| fungi | i get that JayF, i also don't +2 things i'm not willing to help debug, but also it's possible i'm willing to debug things i don't fully understand (for me the most understanding comes through pain) | 21:54 |
| JayF | fungi: for ironic, typically that line is more about access/understanding of particular hardwares more than anything else | 21:54 |
| sean-k-mooney | i expect that is true fo cinder and cyborg too | 21:55 |
| JayF | fungi: and I will override that sorta, personal policy, if it's needed badly enough and another core asks | 21:55 |
| fungi | yep, definitely feel that too | 21:55 |
| JayF | (my name is forever attached to +2'ing parts of irmc driver :C) | 21:55 |
| sean-k-mooney | i think that also a fair point, we dont often have a way to fine a next generation of maintainers | 21:56 |
| sean-k-mooney | for part of code we currently maintain that may nolonger alight ot our intrests or job roles | 21:56 |
| JayF | sean-k-mooney: I think statements like that are sorta incorrect? There is a core reviewer on Ironic now, cid, who is homegrown -- he did an MLH fellowship at GR-OSS and worked his way up in knowledge. But I also know we tend to set the bar at more of a "do we trust this person to know their limits" moreso than "do they know the whole codebase" | 21:57 |
| fungi | my background as a sysadmin has likely hardened me to accepting that i'm going to end up having to figure out random things i'm unfamiliar with on no notice. thankfully these days it doesn't come with being on a conference call with the ceo of some fortune 500 company who expects you to figure out what broke while he's yelling at you that he's losing a million dollars a minute | 21:58 |
| fungi | in sales | 21:58 |
| sean-k-mooney | i was more thinking of findign maintainer of niche depencies in oslo or seldom used codepaths and integrations | 21:58 |
| JayF | we're a community; if we get to the point where contributors -- especially ones who work at a company that represents large swaths of openstack contribution -- we only review/fix/etc code that we care about we're gonna die in a hurry | 21:58 |
| clarkb | ya like why are centos 9 stream images published with 0 byte sha256sum files? | 21:58 |
| clarkb | spotz[m]: ^ you might know who to talk to about that? I think the image itself may be unhappy as the test job is unable to convert it from qcow2 to raw as well. But I haven't done any further verification of that locally | 21:59 |
| JayF | and I've had the jobs in the past that I provide that focus, and I've always asserted I needed 20% upstream review time to maintain core review status | 21:59 |
| JayF | clarkb: Julia indicated in #openstack-ironic she has mentioned the state of those mirrors to someone. | 21:59 |
| sean-k-mooney | clarkb: https://mirror.stream.centos.org/9-stream/BaseOS/x86_64/iso/ | 21:59 |
| clarkb | JayF: ack thanks. Good to know I'm not the only one noticing the problem | 21:59 |
| sean-k-mooney | the isos artnt but maybe the clodu images are? | 22:00 |
| JayF | clarkb: it broke Ironic's gate, which has been broken since 3am | 22:00 |
| clarkb | sean-k-mooney: https://cloud.centos.org/centos/9-stream/x86_64/images/ the CentOS-Stream-GenericCloud-x86_64-9-latest.x86_64.qcow2 image is the one dib tries to build with | 22:00 |
| JayF | clarkb: that's why clif wrote that change, to help us catch it, and then we learn the 0 byte shasum stuff | 22:00 |
| clarkb | JayF: ack | 22:00 |
| JayF | (Clif is a GR-OSS contributor if you haven't met him yet, he's working on the Ironic dynamic networking stuff) | 22:01 |
| sean-k-mooney | oh the latest one sare becasue i think thoes are just symlinks | 22:01 |
| sean-k-mooney | but the ones that have a date also have a size | 22:01 |
| sean-k-mooney | but ya that is jsut i guess i have no idea who to ask | 22:02 |
| clarkb | the latest dated ones have no size and the same image size as the -latest | 22:02 |
| clarkb | so yes probably a symlink but the image underlying it is broken I thin | 22:02 |
| sean-k-mooney | CentOS-Stream-GenericCloud-9-20240828.0.x86_64.qcow2.MD5SUM seams valid | 22:03 |
| sean-k-mooney | my guess is that some automation got interupted | 22:03 |
| JayF | the point is that it's incomplete | 22:03 |
| JayF | yep, and we are the CI for their automation | 22:03 |
| JayF | which is ridiculous | 22:03 |
| sean-k-mooney | it looks like 2025-08-13 03:34 was the last successful one | 22:04 |
| sean-k-mooney | but ya debuging randome thing like that is soemthign we all have to do form time to time | 22:05 |
| fungi | for some of us, debugging random stuff is what we do most of the time | 22:05 |
| fungi | i've spent most of my career accepting that i can't really plan in advance what i'm going to end up working on from one day to the next | 22:06 |
| sean-k-mooney | ya i think we all spend a lot of our tiem doign that in one way or anohter | 22:07 |
| JayF | fungi: I think it's almost a skill/specialty to be a gap filler. That's always where I end up on any team I am on. | 22:07 |
| fungi | which i'm sure would drive a lot of people absolutely batshit | 22:07 |
| JayF | fungi: working on VMT is one of the more fun gaps to fill though :D | 22:07 |
| JayF | fungi: have you met me? have you met you? /s | 22:07 |
| JayF | lol | 22:07 |
| sean-k-mooney | by the way i dont know if we have strated to far form cardoe's orginal feedback | 22:07 |
| sean-k-mooney | but all of this is work that all teh cores do too in addtion to review upstream and downstream | 22:08 |
| fungi | i can guarantee we have ;) | 22:08 |
| sean-k-mooney | like myslef and gibi are disccuion failurues in qemu-iamge that only happen on ubuntu with ceph and luks where it is uessign too much adress_space... | 22:08 |
| sean-k-mooney | that set of endge case fo and edge case debuging happen and we have to balance that with review or other work | 22:09 |
| fungi | and yeah, to that point, this random sea of churn is also what people trying to contribute their own changes are dealing with in their individual worlds | 22:09 |
| cardoe | It will never be perfect. | 22:09 |
| cardoe | We were discussing that some projects are problematic because the TC never knows the PTL election state, etc. | 22:10 |
| cardoe | JayF suggested that possibly our governance was out of line with their working expectations. | 22:10 |
| sean-k-mooney | i guess one thing to realsie si openstack is a complex distitbute system that requried multi displiary knowlsage ot deploy adn run | 22:10 |
| JayF | cardoe: I've said multiple times, including when I was on the TC, that OpenStack governance is heavy and is very good for active projects and bad for inactive ones. I think we'd do many of these projects a favor if we'd find some way to let them keep their names and move to self-governed. | 22:11 |
| cardoe | And I was merely bringing to light there's more to a healthy project than PTL election and interaction with the TC as well. | 22:11 |
| sean-k-mooney | and as a reasult can require a any new contibutor to learn a lot to fix there somall issue | 22:11 |
| cardoe | JayF: Yep. I agree with you. | 22:11 |
| cardoe | I've done a bit of my own skunkworks surveying like fungi did. | 22:12 |
| sean-k-mooney | JayF: well each proejct does get to chose there process for the msot part. at least in terems of hwo they plan and deliver work | 22:12 |
| cardoe | And have pressed senior leaders at companies to have their employees be given the space to get involved and contribute. | 22:12 |
| clarkb | there was a lot more pressure for uniformity a while back. But relaxing that approach was taken to reduce burden on smaller projects iirc | 22:13 |
| JayF | sean-k-mooney: yeah, that's really the one thing I've figured out that helps with nova; you all have your own cadence that doesn't always mash up with expectations for most folks. Once I got to the point of knowing I need spec up months in advance, and to not expect reviews on code until very late in the cycle I got to relax a little. | 22:13 |
| fungi | there are also fundamental laws of entropy at work in any long-lived project, where things like governance naturally increase in complexity. adding requirements is easier/more accetpted than removing them | 22:13 |
| JayF | sean-k-mooney: I'll note this lead time has 100% led to features that likely in a vacuum would be implemented somewhere else ending up in Ironic | 22:13 |
| clarkb | once upon a time the only exception was swift. You had a lot of consistency in basically everything else from code base to processes to governance | 22:14 |
| fungi | for many years, everything that wasn't swift was forked from nova | 22:14 |
| clarkb | ya that certainly helped. Though we had explicit efforts to get them to reconform after diverging. The logging efforts for example | 22:15 |
| fungi | consistency was "inherited" | 22:15 |
| clarkb | anyway I call that out because its possible there may be some value in doing more of that again. I don't know | 22:15 |
| clarkb | (it helped we had the whole elastic recheck carrot with the logging stuff too) | 22:16 |
| sean-k-mooney | ya the fact swift does not use oslo.log/config has come up before a few tiems | 22:16 |
| clarkb | being the same gave developers in different teams direct benefits even if they didn't interact with one another | 22:16 |
| sean-k-mooney | i think even project that have forked fomr not have divered enought now that whiel some part are famialr there is enough varion in the detail that some things can be surprising | 22:17 |
| sean-k-mooney | JayF: for what it worth part of that is because most of the nova core team has very littel time to work on upstream out of our weeks | 22:18 |
| sean-k-mooney | redhat does nto have sepreate upstream and downstream teams or upstrema only folks | 22:18 |
| JayF | sean-k-mooney: it's disappointing that Red Hat has not prioritized community building enough to give you the necessary time to be more effective | 22:19 |
| fungi | once upon a time, there were ci jobs to copy code from nova to other projects daily (not that i recommend going back to that, it's how we eventually ended up with oslo libraries) | 22:19 |
| sean-k-mooney | well we have a large amount of freedom ot chosoe what we work on but wer are very interupt heavy | 22:19 |
| sean-k-mooney | just fo context https://tinyurl.com/35mj48k4 | 22:21 |
| sean-k-mooney | those are the nova review stat fo the last 90 days | 22:21 |
| sean-k-mooney | steph an i dont offically work on teams that maintain nova anymore for over a year | 22:22 |
| sean-k-mooney | im offically ment to be focusing on watcher but i care most about the nova and related project and im trying to be a good stward of watcher | 22:23 |
| sean-k-mooney | to enable others | 22:24 |
| sean-k-mooney | i do alot of my upstream work because i belive its good for the comunity and as a reuslty might eventually benift my emploer althoguh given our product is based on 2023.1(antelop) there is a very very long lead tiem for our feature to reach our customers | 22:26 |
| JayF | sean-k-mooney: I have a similar lead time to my downstream fwiw. Exactly zero features I've developed at this job are deployed downstream (yet). | 22:27 |
| sean-k-mooney | for what its worth when we were discsussing the new lifecylce cadance a few year ago. i really wanted use to shorten the release cycel to 6 weeks and pick 1 relase a year to supprot for 2 year. simialr to what the kernel does | 22:28 |
| sean-k-mooney | i.e do feature release often, still limit the number of releas we need to suprpto to 1 new release a year and supprot upgrade between any point release and the next lts release and between lts releses | 22:30 |
| sean-k-mooney | that way we never have long lead times of mont between proposing a feature and shipting it | 22:30 |
| sean-k-mooney | if it not ready it just slips to the next release in 6 week instead of 6 months | 22:30 |
| JayF | Ironic does a release every 2 months, I believe metal3.io is the primary consumer of it | 22:31 |
| JayF | you described basically the ironic concept of bugfix branches, except we only support those 6 months | 22:31 |
| sean-k-mooney | similar i guess | 22:32 |
| opendevreview | Yasufumi Ogawa proposed openstack/election master: Add Yasufumi Ogawa candidacy for Tacker PTL 2026.1 https://review.opendev.org/c/openstack/election/+/957986 | 22:32 |
| sean-k-mooney | i was really jsut tinkingof how kernels work and the lts release they select each year (the last release of the year) | 22:32 |
| sean-k-mooney | we used ot aim for master to be continuesly deployable into production | 22:33 |
| fungi | still seems like a good goal | 22:34 |
| sean-k-mooney | we still try to some degress | 22:34 |
| opendevreview | Carlos Eduardo proposed openstack/election master: Add Carlos da Silva candidacy for Manila PTL https://review.opendev.org/c/openstack/election/+/957987 | 22:34 |
| sean-k-mooney | ok ist nearign midnight so i will wish ye all good timzone o/ | 22:35 |
| fungi | merry timezone and many happy returns to you as well | 22:36 |
| JayF | \o | 22:36 |
| opendevreview | Merged openstack/security-doc master: OSSN-0094: Ensuring Volume Safety w/Nova & Watcher https://review.opendev.org/c/openstack/security-doc/+/957812 | 22:42 |
| spotz[m] | clarkb: Got pinged by Julia there's a ticket open and I know the person it's assigned to. | 22:42 |
| spotz[m] | Sorry was in another window | 22:42 |
| spotz[m] | https://issues.redhat.com/browse/CS-2983 | 22:44 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!