| *** bauzas_ is now known as bauzas | 01:15 | |
| *** bauzas_ is now known as bauzas | 13:14 | |
| *** bauzas_ is now known as bauzas | 13:41 | |
| opendevreview | Elod Illes proposed openstack/openstack-manuals master: [glossary] Add 2025.1 Epoxy https://review.opendev.org/c/openstack/openstack-manuals/+/930330 | 13:47 |
|---|---|---|
| opendevreview | Elod Illes proposed openstack/openstack-manuals master: [www] Setup 2025.1 Epoxy and add project data to Dalmatian https://review.opendev.org/c/openstack/openstack-manuals/+/930331 | 13:47 |
| opendevreview | Elod Illes proposed openstack/openstack-manuals master: [www] Set 2024.2 Dalmatian as released https://review.opendev.org/c/openstack/openstack-manuals/+/930332 | 13:47 |
| opendevreview | Elod Illes proposed openstack/openstack-manuals master: Fix lint issue 'D001 Line too long' https://review.opendev.org/c/openstack/openstack-manuals/+/930338 | 14:32 |
| frickler | elodilles: ^^ do you also want to look into running the sitemap update? cf. https://review.opendev.org/c/openstack/openstack-manuals/+/914616 and the reference there | 15:40 |
| elodilles | frickler: hmm, i forgot about that one. the patch mentions a script. do you know where that is? | 15:45 |
| elodilles | oh, it's linked in the commit message :X | 15:45 |
| opendevreview | Merged openstack/openstack-manuals master: Fix lint issue 'D001 Line too long' https://review.opendev.org/c/openstack/openstack-manuals/+/930338 | 15:48 |
| frickler | elodilles: yes, we'll likely want to drop zed and 2023.1 from the index by now, too. also there is a doc that describes the process in detail, let me search that once again | 15:48 |
| frickler | that's part of https://opendev.org/openstack/openstack-manuals/src/branch/master/doc/doc-contrib-guide/source/release/taskdetail.rst | 15:52 |
| elodilles | well, 2023.1 is still maintained for ~1 month, so maybe we can drop it at that time (if we don't forget :)) | 15:54 |
| frickler | only slightly related, https://docs.openstack.org/install-guide/openstack-services.html seems to be missing 2024.1, I'd also think it should no longer list EOL releases | 16:00 |
| frickler | let me suggest a patch | 16:01 |
| opendevreview | Dr. Jens Harbott proposed openstack/openstack-manuals master: install-guide: Add 2024.1 and drop old releases https://review.opendev.org/c/openstack/openstack-manuals/+/930356 | 16:09 |
| opendevreview | Dr. Jens Harbott proposed openstack/openstack-manuals master: install-guide: Add 2024.2 release https://review.opendev.org/c/openstack/openstack-manuals/+/930357 | 16:09 |
| frickler | elodilles: https://review.opendev.org/c/openstack/openstack-manuals/+/930331/1/www/project-data/2024.2.yaml has retired stuff like openstack-chef, where did you copy that from? | 16:12 |
| elodilles | frickler: yeah sorry, i usually run it on gate to see there all retired things and update the patch afterwards so that it's easier to review | 16:13 |
| opendevreview | Tim Burke proposed openstack/governance master: Appoint Tim Burke as PTL for Swift https://review.opendev.org/c/openstack/governance/+/928881 | 16:15 |
| frickler | elodilles: ah, I think that's because it was only commented out for 2024.1? we should really delete stuff that is permanently gone IMO | 16:18 |
| gouthamr | tc-members: a gentle reminder that we are meeting here in ~45 minutes | 17:15 |
| cardoe | frickler: speaking of links to releases, I've been thinking about pitching out for the "outdated release" banner to have a link for this current doc in latest. Which might not always work due to re-organization. | 17:48 |
| JayF | that'd be great | 17:49 |
| spotz[m] | o/ | 17:59 |
| gouthamr | #startmeeting tc | 17:59 |
| opendevmeet | Meeting started Tue Sep 24 17:59:58 2024 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:59 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:59 |
| opendevmeet | The meeting name has been set to 'tc' | 17:59 |
| 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. | 18:00 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 18:00 |
| gouthamr | #topic Roll Call | 18:00 |
| noonedeadpunk | o/ | 18:00 |
| spotz[m] | o/ | 18:00 |
| gmann | o/ | 18:00 |
| cardoe | o/ | 18:00 |
| bauzas | \o | 18:01 |
| frickler | \o | 18:01 |
| slaweq | o/ | 18:02 |
| gouthamr | nearly there | 18:02 |
| gouthamr | courtesy ping: gtema | 18:02 |
| gouthamr | no noted absences today; i'm taking this meeting from a parking lot on a hotspot :D so, please accept my apologies to throw the chair at a couple of people that are aware | 18:04 |
| gouthamr | #chair gmann | 18:04 |
| opendevmeet | Current chairs: gmann gouthamr | 18:04 |
| gouthamr | ^ just in case | 18:04 |
| gmann | +1 | 18:04 |
| spotz[m] | We do some meetings where everyone is the chair:) | 18:05 |
| gouthamr | haha, like musical chairs, except we never drop a chair | 18:05 |
| gouthamr | alright, 5 mins have passed.. lets get started | 18:05 |
| spotz[m] | Well and everyone can use the commands if needed:) | 18:05 |
| gouthamr | #topic Results of the Combined TC/PTL Elections for 2025.1 | 18:05 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/TBFUH5LTDHDDBOOOOM5AOCL3Z6DHXX6B/ (2025.1 Epoxy: Technical Committee & PTL Election Conclusion & Results) | 18:06 |
| gouthamr | lets begin by welcoming cardoe and bauzas | 18:07 |
| gouthamr | and welcoming back, gmann and frickler | 18:07 |
| frickler | \o/ | 18:07 |
| slaweq | congratulations!!! | 18:07 |
| JayF | o/ congrats | 18:07 |
| cardoe | \o | 18:07 |
| gmann | o/ | 18:07 |
| spotz[m] | Congrats all! And thank you again Jay and Dan!! | 18:07 |
| gmann | yeah thanks JayF and dansmith for your great contribution in TC | 18:08 |
| noonedeadpunk | ٩(^ᴗ^)۶ | 18:08 |
| gouthamr | ++ thank you JayF and dansmith | 18:08 |
| gouthamr | lets continue clinking our glasses/mugs to all the people that volunteered to be PTLs (and project liaisons) | 18:08 |
| bauzas | thanks :) | 18:08 |
| spotz[m] | Congrats and thank you PTLs! | 18:09 |
| gouthamr | and keep the applause going to slaweq and ianychoi who did a great job with these elections :) | 18:09 |
| frickler | +1 | 18:09 |
| bauzas | ++ | 18:09 |
| slaweq | thx, it was my first time in that role :) | 18:09 |
| cardoe | well it was smooth. great work | 18:09 |
| gouthamr | bauzas cardoe: /me meant to check earlier if you had a chance to look through the onboarding material.. | 18:10 |
| cardoe | yes | 18:10 |
| gouthamr | perfect; thank you.. we use multiple emails, i realize I didn't check what your preferred one was.. | 18:11 |
| gmann | slaweq ianychoi thanks for running the show and great job | 18:11 |
| gouthamr | for anyone else looking, the TC onboarding email looked like this: | 18:11 |
| bauzas | I saw it :) | 18:11 |
| gouthamr | #link #link https://etherpad.opendev.org/p/os-tc-onboarding (TC Onboarding) | 18:11 |
| gouthamr | 18:11 | |
| gouthamr | #undo | 18:11 |
| opendevmeet | Removing item from minutes: #link https://etherpad.opendev.org/p/os-tc-onboarding | 18:11 |
| gouthamr | #link https://etherpad.opendev.org/p/os-tc-onboarding (TC Onboarding) | 18:11 |
| gouthamr | the TC gerrit group has been adjusted as well, which means, please do verify if you have rollcall voting rights as well | 18:12 |
| gouthamr | #link https://review.opendev.org/admin/groups/c88faeb0c52f35ee530be8defcc9627ea87b28df (TC Gerrit Group) | 18:12 |
| gouthamr | as is procedure, we're onto the next task of picking a TC chair.. i pbkac'ed this one a little bit.. | 18:13 |
| gouthamr | as gmann pointed out yesterday, we should have actively encouraged chair nominations for three days past the election cycle | 18:13 |
| bauzas | gouthamr: I checked it, and I got the rollcall-vote | 18:13 |
| gouthamr | bauzas++ ty | 18:13 |
| gouthamr | #link https://review.opendev.org/q/topic:%222025.1-tc-chair%22 (2025.1 TC Chair Candidates) | 18:14 |
| frickler | looks like no election needed, another round of gratulations due? ;) | 18:15 |
| gmann | As there is only one nomination, we do not need election and gouthamr can directly propose a gerrit change to add 'chair' in TC member list page | 18:15 |
| bauzas | I'm fine with this | 18:15 |
| gouthamr | ++ thank you; i'll propose the change after this meeting.. | 18:15 |
| gmann | yeah, congrat and thanks gouthamr for continuing helping in that role | 18:15 |
| bauzas | congrats gouthamr | 18:15 |
| gouthamr | would any one like to be vice-chair? | 18:15 |
| bauzas | and indeed thanks | 18:15 |
| spotz[m] | woohoo congrats:) | 18:16 |
| cardoe | thank you for continuing to be the chair gouthamr | 18:16 |
| gouthamr | i did lean on frickler quite a bit, as i did on everyone else on the TC :D | 18:16 |
| gouthamr | thank you and you're welcome... i'm learning to do this well, publicly and you've been gracious teachers :) | 18:16 |
| frickler | didn't seem too bad to me, but I'd be happy for anyone else to take over | 18:16 |
| noonedeadpunk | I can try to volunteer though also would be happy if someone has more will :D | 18:17 |
| noonedeadpunk | (or time) | 18:17 |
| bauzas | not my will :) | 18:17 |
| spotz[m] | Vice chair is a good way to get experience and learn more about the governance and such | 18:18 |
| bauzas | (I'm already the Nova PTL... :) ) | 18:18 |
| * gouthamr sheesh, that's not enough workload | 18:18 | |
| noonedeadpunk | haha | 18:18 |
| gmann | :) | 18:18 |
| bauzas | noonedeadpunk: propose your name ! | 18:18 |
| gouthamr | awesomesauce, we can do this in one change.. if anyone else has a strong urge (and time, as noonedeadpunk noted) to do it, please do speak up now | 18:19 |
| noonedeadpunk | will push a change then | 18:19 |
| noonedeadpunk | if nobody will | 18:20 |
| * gouthamr we're all so kind | 18:20 | |
| gouthamr | https://www.youtube.com/watch?v=ArsrKHYn5v4 | 18:20 |
| gouthamr | we'll move to the next order of business | 18:20 |
| gouthamr | thanks a lot for being an awesome vice chair frickler | 18:21 |
| gouthamr | thank you noonedeadpunk for stepping up | 18:21 |
| gouthamr | #topic TC weekly meeting times | 18:21 |
| gmann | ++ thanks frickler for your time and help in that role | 18:21 |
| spotz[m] | Thanks Frickler! | 18:22 |
| gouthamr | we've noted that this current meeting time is quite late in the day for those of us in EMEA; | 18:22 |
| gouthamr | this is a good time to see if we can move it | 18:22 |
| gtema | Yes, pretty late | 18:22 |
| gouthamr | #link https://framadate.org/openstacktc-25-1 (Weekly Meeting time poll for 2025.2) | 18:22 |
| bauzas | I'm not *that* opiniated | 18:22 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/governance master: Add TC Vice-chair for 2025.1 https://review.opendev.org/c/openstack/governance/+/930372 | 18:23 |
| * gouthamr her there's gtema | 18:23 | |
| frickler | and there's five of us now :) | 18:23 |
| slaweq | it would be great if could be earlier :) | 18:23 |
| gmann | and considering the daylight saving is coming up soon.. | 18:23 |
| gouthamr | nice; could you please vote on that poll, and i can collate some new slot possibilities | 18:23 |
| gouthamr | true | 18:23 |
| gmann | ++ | 18:24 |
| bauzas | gmann: for US, yeah, but for EU, it will be at the end of October ;) | 18:24 |
| bauzas | gouthamr: ack, will vote | 18:24 |
| * bauzas needs to check his already packed agenda | 18:24 | |
| gouthamr | so, i deliberately removed 1300 UTC from consideration :D | 18:24 |
| bauzas | 1600UTC is like the golden hour everyday | 18:24 |
| gmann | bauzas: yeah, we can consider that also while selecting new time | 18:24 |
| slaweq | yes, and actually after DST change it will be 1h earlier than now, so (at least for me) better :) | 18:24 |
| gouthamr | please vote considering every week from now through March 2025.. including your respective daylight savings time change | 18:25 |
| gmann | yeah | 18:25 |
| bauzas | most of my agenda is packed around that time in the day, everyday | 18:25 |
| spotz[m] | need to get my time calculator out | 18:25 |
| bauzas | spotz[m]: I can calculate for you, I'm sooooo used to it :P | 18:25 |
| gtema | Do we vote now or can it be done async during next few days? | 18:25 |
| slaweq | gouthamr maybe you can prepare doodle so everyone can mark their availability? | 18:26 |
| gouthamr | async ofcourse | 18:26 |
| spotz[m] | I actually have the work calendar configured for UTC and CST/CDT | 18:26 |
| gmann | ++ | 18:26 |
| gmann | slaweq: he did https://framadate.org/openstacktc-25-1 | 18:26 |
| bauzas | mid-Oct, it flips for the US folks (well, the ones that have states using DST :) ) | 18:26 |
| gmann | #link https://framadate.org/openstacktc-25-1 | 18:26 |
| slaweq | sorry, I missed it :) | 18:26 |
| * gouthamr feared you preferred doodle for a minute :) | 18:26 | |
| bauzas | I'm glad Gagenda can now use UTC TZ | 18:27 |
| gouthamr | thanks in advance for adding your times | 18:27 |
| bauzas | Gcal I meant | 18:27 |
| gouthamr | we have a packed agenda, so any other things to be said about $topic? | 18:27 |
| gouthamr | #topic 2024.2 release issues | 18:28 |
| gouthamr | frickler and the release management team noted earlier that we have a bunch of pending RC1 patches | 18:29 |
| gouthamr | #link https://review.opendev.org/q/topic:dalmatian-rc1-deadline+is:open (pending patches affecting the final RC deadline) | 18:29 |
| frickler | these are for projects where the CI was failing | 18:29 |
| gouthamr | these patches were blocked by the release team noting that the respective repo's CI system wasn't passing | 18:29 |
| cardoe | Is kuryr being looked after? | 18:30 |
| gouthamr | that's a good place to start | 18:30 |
| gmann | kuryr deliverable is moved to Zun project team | 18:30 |
| frickler | so we didn't do the "usual" PTL-approval overrides | 18:30 |
| frickler | we pinged hongbin last week, but no progress yet | 18:30 |
| gmann | and kuryr-kubernetes is going to be retired as no volunteer to maintain it | 18:30 |
| gouthamr | #link https://review.opendev.org/c/openstack/releases/+/928532 (kuryr-libnetwork) | 18:30 |
| gouthamr | #link https://review.opendev.org/c/openstack/releases/+/928575 (zun) | 18:31 |
| bauzas | we only have two days for that, right? | 18:31 |
| gouthamr | ^ these two were waiting on zun's contributors/PTL/release managers | 18:31 |
| frickler | also zun itself is broken due to lack of support for sqla 2.0 afaict | 18:31 |
| gmann | humm | 18:31 |
| noonedeadpunk | iirc, Zun also does depend on kuryr | 18:31 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/JJVBOTHRLGPE4WFRQDCGLPTUFTVZ6FKC/ ([cyborg][zun][masakari][tacker][venus] Pending removal of LegacyEngineFacade) | 18:31 |
| gouthamr | ^ related | 18:32 |
| frickler | so the question is: proceed with a forced broken release? or do a late drop from the release? | 18:32 |
| bauzas | which exact projects are we talking about ? | 18:32 |
| gmann | zun and kuryr-libnetwork | 18:33 |
| noonedeadpunk | huh, I don't see masakari importing legacy facade? https://codesearch.openstack.org/?q=LegacyEngineFacade&i=nope&literal=nope&files=&excludeFiles=&repos=openstack/masakari,openstack/masakari-dashboard,openstack/masakari-monitors | 18:33 |
| bauzas | IIRC, there was traction on zun | 18:33 |
| bauzas | but the fact that it was depending on kuryr was creating an issue | 18:33 |
| bauzas | right? | 18:33 |
| gmann | seeing integration jobs also failing, I do not think it is good idea to release the broken things | 18:34 |
| frickler | https://review.opendev.org/c/openstack/zun/+/928655 is the failing test patch | 18:34 |
| gouthamr | gmann: frickler: specifically regarding kuryr-libnetwork, the only changes since 13.0.0 are bot changes | 18:34 |
| bauzas | couldn't we add a release note saying "well, we released it but $bugs" ? | 18:34 |
| frickler | and I don't see any activity to fix zun recently | 18:34 |
| frickler | https://review.opendev.org/q/project:openstack/zun | 18:35 |
| gmann | bauzas: but we do not know what all bugs as someone need to check ehat exact bugs and after that it will work | 18:35 |
| bauzas | I see | 18:35 |
| bauzas | so this would be a blank check | 18:35 |
| gmann | yeah | 18:35 |
| frickler | we could only advise zun deployments to not upgrade at this time | 18:35 |
| * gouthamr actually; there're no changes in zun since 13.0.0 either | 18:35 | |
| gmann | I think that is better way to handle it | 18:36 |
| gmann | and maybe this can trigger users of it come forward and help | 18:36 |
| gmann | as i remember, its just hongbin taking care of it | 18:36 |
| bauzas | zun is cycle-with-rc, right? | 18:36 |
| bauzas | shouldn't we change it to independent ? | 18:37 |
| gouthamr | https://github.com/openstack/zun/compare/master...13.0.0 | 18:37 |
| gouthamr | https://github.com/openstack/kuryr-libnetwork/compare/master...13.0.0 | 18:37 |
| frickler | bauzas: we could propose that for next cycle | 18:37 |
| noonedeadpunk | just today I had a chat with some Zun user. But dunno how they will wanna step in. And they don't have very good record frankly speaking | 18:37 |
| frickler | but also it would still be broken with current upper-constraints likely. so an issue for uncontainerized deployments | 18:38 |
| bauzas | do we have a strong bond on cycle-with-rc that requires us to ship some RC ? | 18:38 |
| gouthamr | (sorry, comparison was in the wrong direction) | 18:38 |
| gouthamr | https://github.com/openstack/kuryr-libnetwork/compare/13.0.0...master | 18:38 |
| gmann | in next cycle, we should check if project is still ok to continue as Active or not. I would say mark it Inactive in start of next cycle and then go from there if we can release or not | 18:38 |
| gmann | at least, this way we will get more clarity about maintenance for next cycle in advance | 18:39 |
| spotz[m] | How many projects are in this state? | 18:39 |
| bauzas | ++ | 18:39 |
| noonedeadpunk | I'm very skeptical about Zun frankly speaking. As it didn't have enough love for quite some time now. | 18:39 |
| gmann | #link https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#current-inactive-projects | 18:39 |
| noonedeadpunk | And given it's barely maintained itself - it likely also needs kuryr now on top | 18:39 |
| gmann | noonedeadpunk: agree | 18:40 |
| bauzas | but the problem is for this release, right? | 18:41 |
| bauzas | we know it will be broken | 18:41 |
| gmann | this release, I think we should not release and say not to upgrade. consider last cycle release as latest for this cycle also | 18:42 |
| bauzas | gmann: is there anything in the cycle-with-rc model that forces us to release ? | 18:42 |
| bauzas | tbh, I lean towards your opinion, if we know that master is somehow broken, let's keep the precedent as the blessed release | 18:43 |
| noonedeadpunk | I think project needs to be inactive not to release | 18:43 |
| gmann | it should be release for that cycle that is why i think release team might require TC resolution for skipping the rleasae | 18:43 |
| noonedeadpunk | but not sure where it's written | 18:43 |
| noonedeadpunk | and timeline for marking as inactive probably passed | 18:43 |
| noonedeadpunk | *(totally passed) | 18:43 |
| gmann | like we did for murano case last time, we stopped its release by passing a TC resolution | 18:44 |
| gmann | noonedeadpunk: yeah, | 18:44 |
| noonedeadpunk | well murano case was way-way-way worse | 18:44 |
| gmann | #link https://governance.openstack.org/tc/resolutions/20240227-remove-murano-from-2024-1-release.html | 18:44 |
| gmann | noonedeadpunk: but we never know if anything such thing in Zun also | 18:44 |
| noonedeadpunk | and also - we did released known broken services before | 18:44 |
| fungi | '“cycle-with-rc” projects commit to publish at least one release candidate following a predetermined schedule published by the Release Management team before the start of the cycle.' | 18:45 |
| fungi | #link https://releases.openstack.org/reference/release_models.html#cycle-with-rc Cycle With RC model | 18:45 |
| noonedeadpunk | with hope to early backport, maybe before final release | 18:45 |
| spotz[m] | If it's going to break we need to stop it now with another resolution | 18:45 |
| fungi | '“cycle-with-rc” projects commit to produce a release to match the end of the development cycle.' | 18:45 |
| bauzas | fungi: thanks for the clarification | 18:45 |
| fungi | is what i meant to quote | 18:45 |
| bauzas | and yeah it would require a TC resolution then | 18:45 |
| fungi | i guess it's a question of how you interpret that commitment | 18:46 |
| fungi | but yes, probably | 18:46 |
| gmann | I am more inclined to avoid murano case. We do not know if there is any security things there | 18:46 |
| noonedeadpunk | well we don't know this about any project | 18:46 |
| cardoe | So I think a release is a bit of a signal to the world about the health of a project. If you know it's bad and going to fail, avoid releasing. | 18:46 |
| fungi | murano was a case where we said deployments should remove the software asap due to a known and unfixed exploitable vulnerability | 18:46 |
| gmann | we do have maintainers and active maintainers for other projects and gate working | 18:46 |
| gmann | at least those are enough proof. | 18:47 |
| noonedeadpunk | so this per say should not be a concern. And if security thing will raise for project that's passing gates now but won't bother to fix it - won't save us either | 18:47 |
| gmann | or at least, we can be sure that if any such security issue comes then we have project team to fix it. | 18:47 |
| noonedeadpunk | I mean... | 18:48 |
| noonedeadpunk | Are we? | 18:48 |
| gmann | risk is more when we know 1. project gate is broken 2. no one to help to fix it 3. we do not know if anyone there to help fixing in future | 18:48 |
| gmann | its about how much risk we want to take | 18:49 |
| noonedeadpunk | like technically - Zun passes criterias as other projects, except currently broken gates. and we actually don't know - maybe they broke 3 weks ago... | 18:49 |
| noonedeadpunk | There's a PTL for it. | 18:49 |
| noonedeadpunk | As trust is a very subjective thing, kinda. | 18:49 |
| noonedeadpunk | I wonder - can we do RC1 but then don't do final release? | 18:50 |
| bauzas | I don't think we can | 18:50 |
| gmann | honestly saying, i am ok to no release things even they are ready but not ok for taking risk which can endup in Murano like case | 18:50 |
| gouthamr | i'd suggest making our intention to block the release known on the ML for zun (and kuryr-libnetwork).. although in case of kuryr-libnetwork, i don't see any problem not releasing - there aren't any release-worthy changes.. | 18:50 |
| noonedeadpunk | and actually neither for Zun... | 18:51 |
| noonedeadpunk | yeah, that's a good argument. | 18:51 |
| gmann | yeah | 18:51 |
| bauzas | one thought, | 18:51 |
| bauzas | could we tag RC1 on a SHA1 that's exactly the same than Caracal rc1 ? | 18:51 |
| gmann | bauzas: that can be one option. | 18:51 |
| noonedeadpunk | I think checks won't pass for releases repo | 18:51 |
| noonedeadpunk | but not 100% sure | 18:52 |
| bauzas | that's my ask | 18:52 |
| gtema | Just for a "Check-Mark"? | 18:52 |
| bauzas | nothing prevents me to propose a releases patch against any sha1 | 18:52 |
| gmann | we do it for some tempest-plugin but need to check if it is same for cycle-wih-rc also | 18:52 |
| noonedeadpunk | but like - how that's gonna help? | 18:52 |
| bauzas | but I don't know whether jobs would fail | 18:52 |
| bauzas | noonedeadpunk: good call | 18:52 |
| noonedeadpunk | as it'll be same way broken , as no valid changes were merged in the meanwhile anyuway | 18:52 |
| bauzas | if the problem is about being forced to release *something* we trust, then let's release based on our knowledge | 18:53 |
| gtema | Exactly, dummy release is useless and harmful | 18:53 |
| bauzas | because Caracal was broken too ? if so, nevermind my proposal | 18:53 |
| gmann | noonedeadpunk: at least it will handle current release and for next cycle anyways we can mark it inactive and take it forward from there | 18:53 |
| noonedeadpunk | Well, based on the changelog I think we can tell that current master is same way truthworthy as 2024.1 | 18:54 |
| bauzas | \o/ | 18:54 |
| bauzas | but we released caracal | 18:54 |
| bauzas | there are two ways to see it, then :-) | 18:54 |
| gtema | That's a bureaucracy not serving anybody | 18:54 |
| gmann | I am ok with either way 1. not to release 2. release with last working sha (caracal) but not ok with release with broken code | 18:54 |
| spotz[m] | I'm good with 1 or 2 but not broken | 18:55 |
| noonedeadpunk | Caracal is _exactly_ same code | 18:55 |
| noonedeadpunk | so 2 == broken | 18:55 |
| noonedeadpunk | #link https://github.com/openstack/zun/compare/13.0.0...master | 18:55 |
| gmann | humm | 18:55 |
| noonedeadpunk | so you're saying that changes to releasenotes broke project? | 18:55 |
| slaweq | how we released it broken in Caracal then? Do you know maybe? | 18:55 |
| gouthamr | ^ or, sometimes, the CI scripts go out of whack? | 18:56 |
| gmann | good point. it is more of it is broken due to deps things | 18:56 |
| slaweq | or it wasn't broken at that time? | 18:56 |
| noonedeadpunk | we changed u-c since caracal | 18:56 |
| slaweq | ok | 18:56 |
| noonedeadpunk | that's the reason why gates are failing I bet | 18:56 |
| gouthamr | +1 | 18:56 |
| gmann | slaweq: no, bcz it worked on caracal oslo or other depds | 18:56 |
| slaweq | ++ | 18:56 |
| slaweq | thx | 18:56 |
| gmann | noonedeadpunk: I agree with you now, releasing with caracal does not make sense | 18:57 |
| bauzas | ditto | 18:57 |
| bauzas | option 1 for me then | 18:57 |
| * gouthamr time check.. 3 mins | 18:57 | |
| bauzas | and fear the consequences of a non-written rule | 18:57 |
| spotz[m] | #1 | 18:57 |
| noonedeadpunk | I kinda fine to release it "broken" or do just RC1 and tell not to update dependencies if "upgrading" | 18:57 |
| noonedeadpunk | just to follow the process and mark as inactive at very beginning of cycle | 18:58 |
| noonedeadpunk | unless honbin won't chime in and fix gates | 18:58 |
| noonedeadpunk | and backport to 2024.2 | 18:58 |
| gouthamr | how could we have avoided this? tagged a release during M-1/M-2 as a forced release? | 18:59 |
| gmann | ah, that is another good point. if no release then no stable/2024.2 right? | 18:59 |
| gouthamr | ^ yes | 18:59 |
| bauzas | yup | 18:59 |
| noonedeadpunk | there's already 2024.2 afaik | 18:59 |
| bauzas | how so ? | 18:59 |
| gmann | is it? | 18:59 |
| gouthamr | not without the rc1 changes | 18:59 |
| bauzas | yeah unless tooling is broken :) | 18:59 |
| noonedeadpunk | oh, forget it, I'm wrong here | 18:59 |
| gmann | #link https://github.com/openstack/zun/branches/all | 18:59 |
| * gouthamr timecheck .. 1 min | 18:59 | |
| noonedeadpunk | disregard my last comment :) | 19:00 |
| * gouthamr timecheck.. done | 19:00 | |
| gouthamr | alright folks; we must proceed beyond the meeting for this one.. and table the other discussion items to next week | 19:00 |
| fungi | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/UE23ZVPR4BMUR6ZJ4EG55JZL25XZCUYP/ volunteers needed for 2024.2/dalmatian release episode of openinfra live | 19:00 |
| bauzas | but we need to come to an agreeement before end of this week, right ? | 19:00 |
| noonedeadpunk | clean forgot that we create branch from tag in one go nowadays | 19:00 |
| gmann | yeah | 19:00 |
| gouthamr | thank you for the call out regarding the release recap fungi! | 19:01 |
| noonedeadpunk | let's raise a ML asap | 19:01 |
| gouthamr | noonedeadpunk: +1 | 19:01 |
| gouthamr | for the sake of the minutes: | 19:01 |
| gouthamr | thank you all for attending | 19:01 |
| noonedeadpunk | can write it up right after the meeting | 19:01 |
| gouthamr | #endmeeting | 19:01 |
| opendevmeet | Meeting ended Tue Sep 24 19:01:50 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 19:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2024/tc.2024-09-24-17.59.html | 19:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2024/tc.2024-09-24-17.59.txt | 19:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2024/tc.2024-09-24-17.59.log.html | 19:01 |
| gmann | noonedeadpunk: thanks | 19:01 |
| gouthamr | noonedeadpunk: thank you! | 19:02 |
| frickler | just two other quick notes from me: a) I'll be away for the next three weeks, back in time for PTG. b) I still won't participate in zoom meetings, I'd support a motion to stop doing video meetings, though I don't really to expect that to happen (so just fyi) | 19:02 |
| gouthamr | frickler: ty for letting us know! | 19:02 |
| gouthamr | hope you feel better soon | 19:02 |
| gouthamr | noonedeadpunk: https://review.opendev.org/q/topic:dalmatian-rc1-deadline+is:open | 19:02 |
| gouthamr | ^ "ansible-role-thales-hsm" is in a good shape now, i think | 19:03 |
| gouthamr | so the problem is limited to kuryr-kubernetes, zun and kuryr-libnetwork | 19:03 |
| bauzas | all of those repos are tied to the same project, right? | 19:03 |
| gouthamr | bauzas: nope; kuryr-kubernetes is half-way retired | 19:04 |
| gouthamr | zun doesn't depend on it | 19:04 |
| bauzas | https://governance.openstack.org/tc/reference/projects/zun.html | 19:04 |
| bauzas | ah right | 19:04 |
| gouthamr | tacker uses kuryr-kubernetes; but the team doesn't want to maintain it - they're trying to remove their integration with it | 19:05 |
| gouthamr | that work missed the dalmatian cycle | 19:05 |
| gouthamr | so, if kuryr-kubernetes is broken, users of tacker that rely on it are probably affected | 19:05 |
| gmann | yeah https://review.opendev.org/c/openstack/tacker/+/926504 | 19:06 |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: Add 2025.1 TC chair and vice-chair https://review.opendev.org/c/openstack/governance/+/930376 | 19:09 |
| bauzas | the fact that we would miss 2024.2 branches on zun makes me a bit revisiting MHO | 19:09 |
| bauzas | in case some team steps up, they'd appreciate a stable branch for them | 19:10 |
| bauzas | for their needs* | 19:10 |
| gmann | yeah, that make is more worst. I also did not consider this | 19:10 |
| gouthamr | noonedeadpunk: do you mind me doing this in one change: https://review.opendev.org/c/openstack/governance/+/930376 | 19:10 |
| bauzas | I'm honestly more inclined to ship something | 19:11 |
| noonedeadpunk | sure, abandoned mine | 19:12 |
| gouthamr | ty noonedeadpunk | 19:12 |
| * bauzas slips off the chair | 19:14 | |
| bauzas | \o | 19:14 |
| * noonedeadpunk crosses fingers for https://review.opendev.org/c/openstack/zun/+/930377 to pass | 19:21 | |
| * noonedeadpunk will wait for results before ML | 19:22 | |
| gouthamr | noonedeadpunk++ | 19:45 |
| noonedeadpunk | fwiw tps://review.opendev.org/c/openstack/zun/+/930377 is passing for Zun now, so now we'd need PTL to take action and review the patch... | 21:13 |
| noonedeadpunk | I've sent ML | 21:13 |
| gouthamr | noonedeadpunk: very nice; thank you! | 21:25 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!