Wednesday, 2023-03-08

*** amoralej|off is now known as amoralej08:15
ttxhberaud: elodilles : Can we get https://review.opendev.org/c/openstack/reno/+/873024 in? Fixes tests for modern git and would like to include it in reno 4.0.008:39
ttxwhich we need out asap to fix release notes all over08:40
* hberaud looks08:40
ttxonly affects tests08:40
ttxthanks! will update https://review.opendev.org/c/openstack/releases/+/876753 once that lands08:42
hberaudttx: do you know why we can't access jobs logs? 08:45
hberaudexample https://review.opendev.org/c/openstack/releases/+/87656708:45
hberaudI reviewed a couple of this morning and logs seems unavailable all the time08:46
opendevreviewHervĂ© Beraud proposed openstack/releases master: release ironic 21.4.0 and branch stable/2023.1  https://review.opendev.org/c/openstack/releases/+/87657308:51
ttxhmm, no08:53
hberaudttx: other question, the ironic team migrated their patches to release a minor version even if the latest tag doesn't justify it. They want a room for bugfix patches, I think they want a possibility to release bugfix version even for anterior versions, example: 1.3.0 exist, we propose 1.3.1 but they want 1.4.0 to allow them to release 1.3.1 and 1.4.1, I don't think we want08:56
hberaudto allow that, correct?08:56
hberaudttx: example https://review.opendev.org/c/openstack/releases/+/87657208:56
opendevreviewRodolfo Alonso proposed openstack/releases master: [neutron] New Xena releases for Neutron  https://review.opendev.org/c/openstack/releases/+/87682709:15
ttxThey basically want to support additional stable branches (bugfix/) in addition to the openstack-blessed one (stable/). I don't see why we'd object to that, as long as the tooling does not complain too much about it...09:17
hberaudok wfm09:18
ttxas far as release management is concerned, we would ignore those bugfix/* branches09:18
hberaudok09:20
hberaudI wasn't sure09:21
opendevreviewJake Yip proposed openstack/releases master: Release magnum RC1 for Antelope  https://review.opendev.org/c/openstack/releases/+/87541809:24
opendevreviewRodolfo Alonso proposed openstack/releases master: [neutron] New Yoga releases for Neutron  https://review.opendev.org/c/openstack/releases/+/87682809:28
ttxBetween those inaccessible logs and some jobs taking ages to enqueue, I feel like our infra is not in perfect shape today. We should probably refrain from approving stuff until the US crew gets up and looks into it09:51
opendevreviewRajat Dhasmana proposed openstack/releases master: Release cinder RC1 for Antelope  https://review.opendev.org/c/openstack/releases/+/87539709:57
opendevreviewRodolfo Alonso proposed openstack/releases master: Release neutron-tempest-plugin for 2023.1 Antelope  https://review.opendev.org/c/openstack/releases/+/87661610:01
opendevreviewMerged openstack/reno master: Fix scanner tests failing with modern Git  https://review.opendev.org/c/openstack/reno/+/87302410:07
opendevreviewThierry Carrez proposed openstack/releases master: Release reno 4.0.0  https://review.opendev.org/c/openstack/releases/+/87675310:22
opendevreviewRodolfo Alonso proposed openstack/releases master: [neutron] New Yoga releases for Neutron  https://review.opendev.org/c/openstack/releases/+/87682810:30
elodillesttx: sounds OK to me, though as I see zuul is in better shape now: https://zuul.opendev.org/t/openstack/status10:31
elodillesat least I could look at the logs that I opened o:)10:32
elodillesdo you still experience issues?10:32
ttxseems better now10:34
ttxThere are still missing logs for that release failure from yesterday, but I think that one will be refreshed as soon as a new release happens10:34
ttx(publish-tox-docs-releases fail)10:35
ttxelodilles: feel free to review and approve reno 4.0.0 so that we can doublecheck release notes look better10:35
elodillesttx: ack, i will look at the release patch now10:36
elodilles+2+W'd10:39
elodilleslet's see if everything works as expected10:39
opendevreviewRodolfo Alonso proposed openstack/releases master: [neutron] New Zed releases for Neutron  https://review.opendev.org/c/openstack/releases/+/87683510:39
opendevreviewSlawek Kaplonski proposed openstack/releases master: New neutron-lib release for stable/zed  https://review.opendev.org/c/openstack/releases/+/87683710:47
opendevreviewElod Illes proposed openstack/releases master: Release venus-tempest-plugin for 2023.1 Antelope  https://review.opendev.org/c/openstack/releases/+/87662110:56
zigoCinder's release tag is ready for approval: https://review.opendev.org/c/openstack/releases/+/87539710:58
opendevreviewRodolfo Alonso proposed openstack/releases master: [neutron] New Zed releases for Neutron  https://review.opendev.org/c/openstack/releases/+/87683511:00
elodilleszigo: ack, looks OK, +2'd11:03
opendevreviewMerged openstack/releases master: Release reno 4.0.0  https://review.opendev.org/c/openstack/releases/+/87675311:11
opendevreviewMerged openstack/releases master: Branch ironic-P-A-B  https://review.opendev.org/c/openstack/releases/+/87657111:11
opendevreviewMerged openstack/releases master: Branch stable/2023.1 for networking-baremetal  https://review.opendev.org/c/openstack/releases/+/87657411:17
whoami-rajatsorry it took long for cinder, i was trying to get a change in but it seems a lost cause for RC1 as of now, will target that for RC2 (and see if the backport is acceptable)11:26
elodilleswhoami-rajat: ack, thanks. yes, it is a bit late for RC1, and we still have a bit of a time for rc211:40
whoami-rajatelodilles, thanks11:54
*** amoralej is now known as amoralej|lunch12:17
ttxelodilles: we can also approve https://review.opendev.org/c/openstack/releases/+/875418 which will conclude the RC1 list12:25
ttxalso this one https://review.opendev.org/c/openstack/releases/+/87676712:26
opendevreviewMerged openstack/releases master: Release cinder RC1 for Antelope  https://review.opendev.org/c/openstack/releases/+/87539712:36
opendevreviewElod Illes proposed openstack/releases master: Add Horizon Antelope cycle highlights  https://review.opendev.org/c/openstack/releases/+/87676712:40
elodillesttx: magnum patch +2+W'd; I've updated the horizon patch ^^^ as there were some wording mismatch o:)12:42
elodillesttx: also, there are quite many approved tempest plugin patches that need a 2nd review, if you have time o:) https://review.opendev.org/q/topic:antelope-tp-latest+label:PTL-Approved12:44
ttxwanted to check if reno 4 kicks in first12:50
opendevreviewMerged openstack/releases master: Release magnum RC1 for Antelope  https://review.opendev.org/c/openstack/releases/+/87541812:51
elodilleswe can test that with the nova patch13:00
ttxnot sure how to test it13:03
elodilleswell, i guess 1st this needs to be merged: https://review.opendev.org/c/openstack/requirements/+/87684613:04
elodillesand then recheck this: https://review.opendev.org/c/openstack/nova/+/87655313:04
elodillesthough, of course it can be tested by a local run of the above patch with bumped upper constraints ^^^13:04
elodillestested it locally and reno was generated fine with reno===4.0.0 \o/13:16
elodillesso we need the req bump patch to merge and the nova patch will pass13:16
elodillesbut now i have to disappear for about an hour13:19
*** elodilles is now known as elodilles_afk13:20
ttxok pinging prometheanfire to approve https://review.opendev.org/c/openstack/requirements/+/87684613:37
ttxwill push it tomorrow morning in case he does not get to it today13:38
*** amoralej|lunch is now known as amoralej13:44
rosmaitahello ... what was the final decision on the proposal to EOL rocky and stein openstack-wide?13:54
*** elodilles_afk is now known as elodilles14:58
elodillesrosmaita: hi, well, to tell you the truth, i forgot about that mail thread o:)15:04
elodillesrosmaita: i wanted to wait a bit to get some more opinions15:05
rosmaitalooks like zigo is against it, everyone else is in favor!15:05
rosmaitaelodilles: i couldn't remember if you were going to do openstack-wide, or individual projects should propose patches15:06
elodillesrosmaita: i wanted to do it openstack-wide15:06
rosmaitai'm asking because the cinder rocky gate is hosed, and there's no point fixing it if it's about to go EOL15:07
elodillesrosmaita: considering that some of the core projects have already EOL'd their rocky branches (neutron, nova)15:07
rosmaitaelodilles: exactly15:07
elodillesrosmaita: the question is now whether cinder team would accept patches without gate jobs15:08
rosmaitaelodilles: no, definitely not15:08
rosmaitawell, that's me, i shouldn't speak for the whole team these days15:08
elodillesrosmaita: yeah, i'm in the same opionion, some level of gate jobs are definitely needed15:09
elodillesand unfortunately rocky and stein gates are completely broken for most of the projects15:10
elodilles(as I can see these are the latest mails in the topic: https://lists.openstack.org/pipermail/openstack-discuss/2023-February/thread.html#32018 )15:11
rosmaitaelodilles: i guess my question is, should we wait for the openstack-wide retirement, or should we push cinder project patches now to EOL rocky and stein?15:14
rosmaitadoes it make any difference to the release team?15:14
zigorosmaita: This is a very bad sum-up of my opinion. I'm not against making EOL, and stop having a gate, I'm just against removing any possibility to push and share security fixes to the branch (even without a gate).15:32
elodillesrosmaita: the same patches need to be proposed, so actually it does not make a difference15:33
rosmaitazigo: ack, sorry to mischaracterize15:34
elodilleszigo: EOL means the branch is deleted, so that at least is contradicting15:34
zigoRight...15:35
zigoFeel free to ignore me anyways ... :)15:35
rosmaitawell, i think what zigo is after is EOL and no more patches, but the branch is kept so that patches can be posted to gerrit and discussed in public15:35
rosmaitai mean, no more merged patches15:35
zigorosmaita: Exactly, you got my point !!! :)15:35
zigoWe could merge patches after at least 2 distros validated them, for example. But no need to have the extra effort to maintain a gate, as downstream distros (like me with Debian...) have other ways to test patches.15:36
elodilleshmmm, that is interesting. as far as I know gerrit does not allow patches against non-existing (deleted) branches, but maybe i'm wrong15:36
zigoFYI, I managed to break Rocky, Stein and Train for Nova ! :)15:36
zigoelodilles: That's the point, we need to keep at least the branches.15:37
rosmaitaelodilles: i think you are correct, so we would have to change the policy about deleting EOL branches15:37
rosmaitai guess we could have a "community maintenance" mode for those branches, where the openstack project team is no longer responsible for what goes on in those branches15:38
rosmaitathough now that i said it out loud, it sounds like a recipe for disaster15:38
rosmaitaor maybe not15:39
rosmaitai guess we could have responsible "community-maintenance-cores" with some kind of vetting process15:39
elodillesthe problem i think (what I remember; i wasn't there in the early days of OpenStack) is that people would propose patches against EOL'd branches and teams would end up with a bunch of open patches that no one ever reviews, or even finds, when it is needed for them.15:40
elodilleseven Extended Maintenance exists with the same purpose: to let people cooperate and propose bugfix backports. unfortunately even EM branches are poorly maintained15:41
opendevreviewRodolfo Alonso proposed openstack/releases master: Release neutron-tempest-plugin for 2023.1 Antelope  https://review.opendev.org/c/openstack/releases/+/87661615:41
elodillesmaybe this is a good topic for teams or PTLs or for the TC @ PTG15:42
elodilleszigo: in my opinion, in rare cases (like Security bug fix backports to EOL'd branches), there is the possibility, to add a patch to the bugreport15:45
elodilleszigo: if i remember well team members offered the help in the recent case as well, so when a patch is in a good shape, discussed with project teams, it can be attached to the bug report15:47
elodilleszigo: would that end up with the same result that you want with keeping branches open?15:48
elodilleszigo: and it could be ease to find (sometimes even easier than to find in gerrit)15:48
zigoelodilles: Well, for the VMDK vuln, we had no help from upstream for any branch before Ussuri in Nova...15:51
zigoBecause it needed more patches to be backported, probably.15:51
elodilleszigo: hmm, i see, it's still not backported (not even a WIP) for train15:55
elodilleswell, i wanted to help with the review (or even backport) to train, but it lost in my TODO list :S15:58
elodillesanyway, i understand your point, but still, it is more painful to keep old branches open. as those need some kind of maintenance anyway, if not that to keep things operational, then the clean-up time to time, to be able to change / remove old, unused CI jobs, for example16:02
fungiskimming because there's a lot of discussion here, but just to reiterate, extended maintenance doesn't require that there be any jobs run for those branches, nor that the changes proposed for them will ever necessarily be merged. the whole point of extended maintenance was to provide a place for downstream consumers to be able to share and collaborate on patches rather than all doing16:20
fungithe same redundant work independently. it was never supposed to be a burden on the core review teams for projects, they should only ever have to care about the officially maintained branches and can ignore or delegate control over extended maintenance branches to other people entirely16:20
fungirosmaita: were you under the impression that the health of extended maintenance branches was the responsibility of the project teams?16:21
rosmaitafungi: i know technically it is not, but we do feel a responsibility while they are open16:22
opendevreviewRodolfo Alonso proposed openstack/releases master: [neutron] New Yoga releases for Neutron  https://review.opendev.org/c/openstack/releases/+/87682816:22
fungithey're only "open" so that people can coordinate patches for those branches after they core teams are no longer caring for them. that's why we stop tagging releases once the branches transition to extended maintenance16:24
fungiwould renaming "extended maintenance" to "community maintenance" make it more clear?16:24
fungito me' "community maintained" feels like the alternative to "commercially maintained" (like you find in open-core software)16:25
fungiso i'm not all that keen on the name16:25
rosmaitafungi: yes, i see your point about the name16:34
rosmaitai wonder whether 'unmaintained' would be better16:36
fungii have always felt that we should just combine the extended maintenance and unmaintained states, the distinction for switching between them has always been uselessly vague16:37
fungifor whatever reason, though, people find "unmaintained" to be a scary name even though it means mostly the same as how extended maintenance is already defined16:38
rosmaitai am coming around to your way of thinking16:38
elodillesi also find "community maintained" less scary and more meaningful than "unmaintained"16:49
elodillesbut maybe it's just me :)16:49
fungiwell, regardless the point would be to get rid of the separation between the current extended maintenance and unmaintained states since there's no effective distinction between them. just go from stable maintenance by core review teams with full testing and point releases, to uncoordinated maintenance by interested members of the broader community with limited testing while no longer17:32
fungitagging releases, then to eol once it stops making sense to keep the branch open17:32
funginaming is, as always, the hardest part of the problem17:33
*** amoralej is now known as amoralej|off17:36
opendevreviewMerged openstack/releases master: Add Horizon Antelope cycle highlights  https://review.opendev.org/c/openstack/releases/+/87676717:37
opendevreviewRodolfo Alonso proposed openstack/releases master: [neutron] New Yoga releases for Neutron  https://review.opendev.org/c/openstack/releases/+/87682817:58

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