Thursday, 2021-01-07

*** dave-mccowan has quit IRC00:00
*** evrardjp has quit IRC00:04
*** evrardjp has joined #openstack-release00:05
*** brinzhang has joined #openstack-release00:14
*** armax has quit IRC01:40
*** tinwood has quit IRC02:08
*** tinwood has joined #openstack-release02:11
*** ianychoi__ has joined #openstack-release03:22
*** ianychoi_ has quit IRC03:25
*** mrdoug has joined #openstack-release04:50
*** mrdoug has quit IRC04:55
*** mrdoug has joined #openstack-release04:55
*** mrdoug_ has joined #openstack-release04:56
*** mrdoug_ has quit IRC04:57
*** whoami-rajat__ has joined #openstack-release04:57
*** mrdoug has quit IRC04:58
*** mrdoug has joined #openstack-release04:59
*** ykarel has joined #openstack-release05:03
*** evrardjp has quit IRC05:33
*** evrardjp has joined #openstack-release05:33
*** sboyron has joined #openstack-release07:50
*** slaweq has joined #openstack-release08:06
*** rpittau|afk is now known as rpittau08:37
*** tosky has joined #openstack-release08:39
*** vishalmanchanda has joined #openstack-release09:01
*** dtantsur|afk is now known as dtantsur10:02
*** elod has quit IRC11:01
*** elod has joined #openstack-release11:02
*** mrdoug has quit IRC11:17
*** icey has quit IRC13:09
*** icey has joined #openstack-release13:11
*** e0ne has joined #openstack-release13:20
*** vishalmanchanda has quit IRC13:30
*** e0ne has quit IRC13:33
*** diablo_rojo has joined #openstack-release13:54
*** brtknr has quit IRC13:57
*** irclogbot_1 has quit IRC14:09
*** irclogbot_0 has joined #openstack-release14:13
*** e0ne has joined #openstack-release14:23
*** dave-mccowan has joined #openstack-release14:37
*** slaweq has quit IRC14:37
*** slaweq has joined #openstack-release14:40
*** dave-mccowan has quit IRC14:42
*** e0ne has quit IRC14:44
*** e0ne has joined #openstack-release14:45
*** e0ne has quit IRC14:45
*** armax has joined #openstack-release15:09
*** diablo_rojo has quit IRC15:11
*** slaweq has quit IRC15:22
*** slaweq has joined #openstack-release15:28
openstackgerritHervĂ© Beraud proposed openstack/release-test master: Add doc/requirements  https://review.opendev.org/c/openstack/release-test/+/76977515:50
nicolasbockHi! Who can add me to the designate stable release core group?15:54
hberaudgood question, what's the context?15:54
nicolasbockI am core in the designate projects15:55
nicolasbockBut that doesn't cover my reviews for the stable branches15:55
nicolasbockIn other words I can't approve backports15:55
hberaudit's more a stable branch topic15:55
nicolasbockI couldn't find an iRC channel that had the term 'stable' in it :)15:56
hberaud#openstack-stable15:56
nicolasbockSo maybe this is not the right place to ask this question15:56
nicolasbockOh15:56
nicolasbockThat was easy :)15:56
hberaudlol15:56
nicolasbockThanks hberaud !15:56
hberaudnicolasbock: I would suggest to ask there first and if nobody respond to you then do not hesitate to come back here :)15:57
hberaudnicolasbock: you are welcome15:57
nicolasbockThanks! I just asked there. Let's see if I get a response :)15:58
hberaudack15:58
*** armstrong has joined #openstack-release16:02
* diablo_rojo_phon sneaks in a bit late16:08
diablo_rojo_phonNo meeting today?16:09
hberaudIn 1 hour16:09
hberaud5pm UTV16:09
hberaudUTC16:09
armstrong@diablo_rojo_phon: you sneaked in too early :)16:10
hberaud:)16:10
*** ykarel has quit IRC16:12
diablo_rojo_phonOh oops.16:21
diablo_rojo_phonThat's two meetings today I've been off by an hour for.16:22
hberaudnp16:23
*** elod has quit IRC16:40
*** elod has joined #openstack-release16:40
fungijust a heads up, we had an afs server get stuck in a pathological way from 05:50 utc today until 16:10 utc when we hard rebooted the server instance. this would have impacted things like tarball uploads and release note publication. doesn't look like any release requests merged in that timeframe but if you find something which needs to be rerun, just let me know16:48
openstackgerritMerged openstack/releases master: Release kolla deliverables Victoria RC2  https://review.opendev.org/c/openstack/releases/+/76932216:55
hberaudfungi: ack thanks for the heads up16:57
hberaud#startmeeting releaseteam17:00
openstackMeeting started Thu Jan  7 17:00:18 2021 UTC and is due to finish in 60 minutes.  The chair is hberaud. Information about MeetBot at http://wiki.debian.org/MeetBot.17:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:00
*** openstack changes topic to " (Meeting topic: releaseteam)"17:00
hberaud#link https://etherpad.opendev.org/p/wallaby-relmgt-tracking Agenda17:00
ttxo/17:00
openstackThe meeting name has been set to 'releaseteam'17:00
hberaudPing list: ttx armstrong elod17:00
armstrongo/17:00
hberaudWe're way down on line 194 now.17:00
hberaudWill just wait a couple minutes for folks.17:00
*** diablo_rojo has joined #openstack-release17:01
openstackgerritMerged openstack/releases master: Release kolla deliverables for Ussuri  https://review.opendev.org/c/openstack/releases/+/76932417:01
openstackgerritMerged openstack/releases master: Release kolla deliverables for Train  https://review.opendev.org/c/openstack/releases/+/76932517:01
elodo/17:01
diablo_rojoo/17:01
hberaudLet's just start by saying welcome back and happy new year to everyone, I hope you enjoyed your end of the year parties17:02
ttxsocially-distanced of course17:02
hberaudlol17:02
elod:)17:02
fungivirtuparty17:02
diablo_rojoI am so over virtual anything lol17:03
hberaudSo let's go!17:04
hberaud#topic Assign R-13 tasks17:04
*** openstack changes topic to "Assign R-13 tasks (Meeting topic: releaseteam)"17:04
hberaudSo next week will be the Victoria Cycle-Trailing Release Deadline17:04
hberaudAll projects following the cycle-trailing release model must release their Victoria deliverables by 14 January, 2021.17:04
* ttx checks current status17:05
hberaudI think it could be worth to send a friendly reminder17:05
openstackgerritDmitry Tantsur proposed openstack/releases master: Release ironic-python-agent-builder 2.4.0  https://review.opendev.org/c/openstack/releases/+/76980217:05
hberaudAny volunteer?17:05
ttxa bunch have RCs already17:05
ttxI think it's good if it comes from the release manager. More intimidating and all17:06
hberaudI didn't verified but I agree it could be worth to check before17:06
hberaudYou're right17:06
hberaudI'll check and send!17:06
hberaudthe second thing was "Ahead of MembershipFreeze, run governance_consistency.py" but I see that ttx & armstrong are already on it, thanks!17:07
ttxarmstrong: we could sync on Monday about that?17:08
ttxhmm wait, my schedule is a bit busy17:08
armstrongsounds good to me17:08
ttxearly in the day for you would be good (early afternoon for me)17:08
armstrong@ttx anytime next week looks good to me17:08
ttxMonday 14UTC?17:08
armstrong@ttx Yes17:09
ttxok, meet here if you need help :)17:09
armstrongok17:09
hberaudThen I think we can move the next topic17:09
hberaud*to17:10
hberaud#topic EM for branchless projects17:10
*** openstack changes topic to "EM for branchless projects (Meeting topic: releaseteam)"17:10
hberaudDo we want to continue with EM for branchless projects?17:10
hberaudelod voluntary ignored them, and some of us think that this mixing concept that are separated17:10
ttxI think gmann made a good rationale about why we should accept them17:10
elodactually not just voluntarily but the validator failed if I remember correctly :)17:10
ttxI don't have enough brain cells right now to question the status quo17:11
hberaudelod: Ah sorry I misunderstood17:11
hberaudI'm not against that, it was already did during previous cycle (c.f queens)17:11
ttxone issue is that the patch chain looks weird17:11
ttx(Indirect ancestor and all)17:11
hberaudah17:12
ttxso wondering if approving it will not bork all the others17:12
hberaudmaybe17:12
ttxfungi: what does indirect ancestor mean?17:12
hberaudanother issue is that some of these patch also face the doc issue17:12
hberaudso they need to be rebased on the top of the related patch here => https://review.opendev.org/q/topic:%2522fix-relmgt-pip-doc%2522+(status:open)17:13
hberaudbut we will speak about that more deeply in the next topics17:13
ttxah, a new patchset was posted for it, and now all the patches that were posted on top of it are potentially a problem17:13
*** dtantsur is now known as dtantsur|afk17:13
ttxthey will probably need to be rebased17:14
hberaudok17:14
elodfwiw, if this was done for queens, then it should be approved to stein (and rocky?) as well (of course if the ancestor problem doesn't make any breakage)17:14
hberaudgmann: FYI ^17:14
hberaudelod: yes make sense17:14
fungisorry, which change?17:15
fungiis "indirect ancestor" something gerrit is displaying somewhere?17:15
ttxfungi: I think I got it. was https://review.opendev.org/c/openstack/releases/+/76856617:15
hberaudfungi: https://review.opendev.org/q/topic:%22tempest-plugin-stein-em%22+(status:open%20OR%20status:merged)17:15
ttxit's the inverse of "Not current"17:16
fungiahh, neat17:16
fungii don't think i've seen that before17:16
ttxLike Change 2 is stacked on top of patchset 1 of Change 117:16
ttxbut then you post patchset 2 of Change 117:16
ttxThen change 1 will show as "not current" in change 217:16
ttxand change 2 will be "indirect ancestor" of change 117:17
fungiyep, makes sense, i agree17:17
ttxiiuc17:17
ttxshoudl be safe, but might force rebases for all the patch 2s17:17
*** rpittau is now known as rpittau|afk17:18
fungigerrit will require them to be rebased anyway, because they have ancestor commits which will never appear in the target branch17:18
ttxWith the current state of my brain cells I'll trust gmann and just follow his request17:18
ttxjust posted +217:19
hberaudSo if I summarize, we want to continue with these changes, and we should also update some of our machinery =>  https://review.opendev.org/c/openstack/releases/+/768566 , is it make sense for everyone?17:19
ttxyeah, avoids validation fail17:20
gmannfungi: ttx hberaud i can rebase once it is merged, at least that would not lose hberaud +2 on plugins releases17:20
fungigmann: yep, that should work17:20
ttxok, those need the doc changes before we can process them anyway17:20
gmannttx: which  one?17:20
hberaudttx: before +2 ensure that repo aren't part of https://review.opendev.org/q/topic:%2522fix-relmgt-pip-doc%2522+(status:open)17:21
ttxmost of the *-tempest-plugin fall into http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019612.html17:21
gmannhberaud: I will reply to your comment on 768566, was busy in other things17:21
hberaudok17:21
hberaudttx: yes17:21
gmanni see, got it17:21
hberaudand patches are only on master for now17:22
hberaudWe will risk to have to reenqueue lot of jobs17:23
hberaudit is problematic...17:23
hberaudgmann: Do you think we could deactivate some job on these branches before moving to EOL?17:24
elodjust one question: if we allow EM tagging for branchless repos, is there any other repo that we have to be careful?17:24
elodI mean, e.g. not *tempest-plugin, but other branchless repository17:25
elodif there exists such17:25
hberaudgmann: docs and releasenotes job AFAIK17:25
hberaudgmann: it could solve our issue easily17:25
hberaudand it could be done by using a script17:26
fungiwhat is em tagging for branchless repos?17:26
gmannhberaud: we had same kind of situation in Ocata time when due to stestr we could not run the unit/integration tests there and then it end up going to EOL17:26
gmannfungi: for tempest and tempest plugins, it will be current master has when branch went to EM means this is last compatible version can work against EM branches code17:27
elodfungi: allowing to tag with *-em, regarding this patch: https://review.opendev.org/c/openstack/releases/+/76856617:27
hberaudelse we could simply assume to ignore all the related failing job...17:27
hberaud(doc & releasenotes job fails only)17:28
gmannhberaud: only issue is we would be backport the doc or releasenotes untested and they are EM so not good.17:28
gmannbut at same time we can argue these might be less such changes so as long as we test unit/func/integration we can assume these EM are tested17:29
fungigmann: elod: what is the benefit of adding the *-em tags to tempest?17:30
hberaudand keep them non-EM?17:30
hberaudgmann: ^17:30
fungidoes tempest extended maintenance differ from when tempest drops support?17:30
gmannhberaud: you mean 'unmaintained' ?17:30
gmannfungi: it will help to find the last compatible version of Tempest for that stable branch17:30
hberaudno I mean not moving to EM17:30
fungigmann: "extended maintenance" seems like a very confusing term in that case17:31
fungitempest is ceasing maintenance for that series, not extending it17:31
gmannfungi: i tried to explain these versioning thing for Tempest and plugins here https://docs.openstack.org/tempest/latest/tempest_and_plugins_compatible_version_policy.html17:31
gmannfungi: yeah that is faire point, i used -em along with new version number also so that they can be easily understandable with our stable branch -em tag17:32
fungigmann: yeah, the support policy makes sense, but calling what tempest is doing "extended maintenance" doesn't really match what it describes17:32
hberaudhttps://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#testing17:33
gmannhberaud: I think i lost in your comment, 'keep them non-EM?' 'them' you mean current stable branches or EM branches ?17:33
fungianyway, i don't really have a strong opinion on it, i was simply confused because it initially sounded like you were saying tempest was adding an extended maintenance phase17:33
gmannfungi: or we can say *-eol which will be right thing for Tempest and plugins17:34
ttxAIUI it does not make sense in itself, but is useful to trick the tests to run with the right code17:34
hberaudgmann: np I think I misunderstood you when here "but at same time we can argue these might be less such changes so as long as we test unit/func/integration we can assume these EM are tested"17:35
fungi-eol or -final or -end or something would make more sense, just from a confused user perspective17:35
gmannhberaud: ohk, i mean it for already EM branches.17:35
elodI like -final :)17:35
elodhowever, usually final things won't be finals ;)17:36
hberaudeol could be an option17:36
fungi-final is usually followed by -really-final and then -no-we-mean-it-this-time-final17:36
hberaud:)17:36
elodthat's true :D17:36
gmannone more tricky thing  here is other later version of Tempest might work but this tag is last guaranteed working one17:36
fungiit's the last one you tested with it, right17:37
gmannyeah17:37
gmann-last-compatible ? but it is too long17:37
fungior simply -last17:38
hberaud+1 -last17:38
gmannyeah, that's better17:38
elod-last sounds better to me, too17:38
fungianyway, this is devolving into bikeshedding, so i'm violating my personal policy of bikeshedding on names for things17:38
elodtrue, again :)17:39
gmanncool, I will update it with rebase once 768566 is merged for easy update17:39
gmannhberaud: can you check, i replied to your comment - https://review.opendev.org/c/openstack/releases/+/76856617:40
hberaudWhat do we do if a pip issue appear with these patches and doc/reno, do we assume to ignore them?17:41
* hberaud read17:41
elodone more thing: if we are not using the -em tag for this, then we don't need the validator modification patch either, am I right?17:42
hberaudgmann: ok I'm fine with that, thanks17:43
hberaudelod: I think that yes17:44
openstackgerritThierry Carrez proposed openstack/releases master: molteniron does not need releases  https://review.opendev.org/c/openstack/releases/+/76959717:44
hberaudIMO this patch isn't needed anymore if we use -last17:45
elodas 768566 is specially for -em tag17:46
hberaudYes17:46
hberaudOK, we can get those out after the meeting then. We've other topics to discuss17:46
ttxindeed17:46
hberaud#topic moltiron's abandon, what's the exact process to follow?17:47
elodhberaud: ok, thanks \o/17:47
ttxthe wrong reno should be fixed now?17:47
*** openstack changes topic to "moltiron's abandon, what's the exact process to follow? (Meeting topic: releaseteam)"17:47
ttxOK, I just did work on that17:47
hberaudYes thanks17:47
gmannhberaud: thanks17:47
ttxSo the proper way to express that a deliverable is actually not using releases is...17:47
ttxa release-management: none key in the governance projects.yaml file17:47
hberaudok17:47
ttxI just proposed it in replacement of this patch17:48
ttxThat's the occasion to explain one thing17:48
hberaudawesome thanks (FYI iurygregory)17:48
ttxwhich is not well documented (I'll fix it)17:48
hberaud^17:48
hberaudack17:48
ttxYou can read the commit message on https://review.opendev.org/c/openstack/governance/+/61326817:48
ttxbut basically...17:48
iurygregoryhberaud, np =)17:48
ttxThe TC gives us a list of official openstack deliverables17:48
gmannhberaud: elod ah yeah, let's discuss 768566  after meeting17:49
ttxby default, the Release management team is tasked with doing release management for all of them17:49
ttxBut some are actually not released17:49
ttxand some are released but not by us17:49
hberaudGood to know17:49
gmannttx: i think there was some script to validate those releade model or it was just manual finding if any mismatch?17:49
ttxthose are exceptions that are documented in governance17:49
ttxusing the release-management: none and release-management: external keys17:49
gmanni remember you corrected many in past17:50
ttxindeed. We plan to run that script next week17:50
gmannk17:50
ttxas part of the membershipfreeze17:50
ttxHere since the deliverable was never released it's pretty easy17:50
ttxjust set the key in governance and remove the deliverable file that should never have been created17:50
ttxBut that shows that those keys are not well documented17:51
ttxI'll probably post something to the project-team-guide17:51
gmann+117:51
hberaudack thank17:51
ttxthat is all!17:51
hberaud#topic Wrong reno with (22.0.0.0rc1 is a victoria tag marked as unreleased)17:52
*** openstack changes topic to "Wrong reno with (22.0.0.0rc1 is a victoria tag marked as unreleased) (Meeting topic: releaseteam)"17:52
hberaudI missed this topic previously17:52
hberaudThis is just a heads up17:52
hberaudthe problem have been fixed by https://review.opendev.org/c/openstack/project-config/+/76912817:52
hberaud#topic Remove misleading error message on our jobs17:52
*** openstack changes topic to "Remove misleading error message on our jobs (Meeting topic: releaseteam)"17:52
hberaudAnother heads up17:53
hberaudttx proposed some changes in our tools to avoid misleading logs17:53
hberaudhttps://review.opendev.org/c/openstack/project-config/+/769353, so please keep  an eye open in the very unlikely case it creates a regression.17:53
hberaud#topic releasenotes/docs jobs issues related to pip's latest resolver,17:54
*** openstack changes topic to "releasenotes/docs jobs issues related to pip's latest resolver, (Meeting topic: releaseteam)"17:54
hberaudAnd the last but not the least...17:54
hberaudAs you surely seen previously during our discussion and on the ML we faced some issues with docs/release c.f  http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019611.html17:55
hberaudI asked you to hold our validations for a while17:55
fungiit mostly stems from bugs in projects where they're listing incompatible versions of linters in their test-requirements.txt files17:56
hberaudnow all identified repos received fixes, https://review.opendev.org/q/topic:%2522fix-relmgt-pip-doc%2522+(status:open+OR+status:merged)17:56
hberaudHowever stable haven't been addressed yet17:57
hberaud*branches17:57
hberaudI think we can restart patch valiation but we should take care of the list of projects to see if they are sensitive projects17:59
hberaudelse we will have to reenqueue lot of failed jobs.18:00
hberaudwe reached the end of the meeting time slot18:00
hberaud#topic open discussion18:01
*** openstack changes topic to "open discussion (Meeting topic: releaseteam)"18:01
hberaudAnything else?18:01
ttxnothing from here18:01
elodneither from me18:01
armstrongnothing from me18:01
hberaudLet's discuss about topics that need more time outside of the meeting slot18:01
hberaudOK, thanks everyone. Let's wrap up.18:02
hberaud#endmeeting18:02
*** openstack changes topic to "OpenStack Release Managers office - Come here to discuss how to release OpenStack components - Logged at http://eavesdrop.openstack.org/irclogs/%23openstack-release/"18:02
openstackMeeting ended Thu Jan  7 18:02:23 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:02
openstackMinutes:        http://eavesdrop.openstack.org/meetings/releaseteam/2021/releaseteam.2021-01-07-17.00.html18:02
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/releaseteam/2021/releaseteam.2021-01-07-17.00.txt18:02
openstackLog:            http://eavesdrop.openstack.org/meetings/releaseteam/2021/releaseteam.2021-01-07-17.00.log.html18:02
ttxthanks hberaud !18:02
elodthanks!18:02
gmannttx: hberaud elod I will abandon this as we agreed to use *-last for tempest and plugins - https://review.opendev.org/c/openstack/releases/+/76856618:02
armstrongthanks18:02
hberaudgmann: +1 for -last18:02
elodgmann: ++18:02
gmanncool, thanks18:03
hberaudgmann: notice that it could be worth to document this "state" somewhere to ensure that it's understood by everybody18:04
hberaudand what's your needs and your goal by doing that18:04
hberauds/what's/what was/18:05
gmannhberaud: sure. do you know in which doc i can add that? in this? https://releases.openstack.org/reference/using.html18:12
gmanni was searching if *-em is defined or so but could not find18:12
elod*-em and *-eol are mentioned in the stable policy ( https://docs.openstack.org/project-team-guide/stable-branches.html )18:18
elodbut I don't know whether tags are documented somehwere else officially18:19
gmannelod: thanks, I think i can add it there under the 'Extended Maintenance' section which is the phase we need -last tag also18:21
gmannhberaud: ^^ is that work fine from?18:21
fungihberaud: you mentioned that once the release notes building fixes are implemented in stable branches we'll need to reenqueue things... will we though? those jobs are effectively branchless and the release notes will get correctly refreshed for those projects on their next release for any series18:21
fungis/branchless/branch-agnostic/18:22
*** sboyron has quit IRC18:29
*** sboyron has joined #openstack-release18:29
hberaudgmann: WFM19:02
hberaudfungi: Ah yes exact good point19:02
fungii'm happy to reenqueue anything which needs to be rerun, but i have a feeling we can just ignore most of those19:25
hberaudyes19:26
hberaudanyway as you already said this is issue mostly depends on the alignment of the stars... if req tests are ok even if no doc reqs.txt exist it would be ok19:28
hberaudBut standardization can't hurt and I prefer to be more suspicious than not enough19:30
*** whoami-rajat__ has quit IRC20:02
*** diablo_rojo has quit IRC20:20
*** armstrong has quit IRC20:52
openstackgerritGhanshyam proposed openstack/releases master: [Tempest] Tag stein EM  https://review.opendev.org/c/openstack/releases/+/76856521:17
openstackgerritGhanshyam proposed openstack/releases master: [Tempest] Tag stein-last  https://review.opendev.org/c/openstack/releases/+/76856521:19
openstackgerritGhanshyam proposed openstack/releases master: [Tempest Plugins] Tag stein-last  https://review.opendev.org/c/openstack/releases/+/76854721:20
openstackgerritGhanshyam proposed openstack/releases master: [Tempest Plugins] Tag stein-last  https://review.opendev.org/c/openstack/releases/+/76854721:20
openstackgerritGhanshyam proposed openstack/releases master: [Tempest Plugins] Tag stein EM  https://review.opendev.org/c/openstack/releases/+/76855321:22
openstackgerritGhanshyam proposed openstack/releases master: [Tempest Plugins] Tag stein-last  https://review.opendev.org/c/openstack/releases/+/76855321:22
*** noonedeadpunk has quit IRC21:47
*** noonedeadpunk has joined #openstack-release21:48
*** jbadiapa has quit IRC23:21
*** tosky has quit IRC23:53

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