17:00:20 <hberaud> #startmeeting releaseteam
17:00:21 <openstack> Meeting started Thu Feb 18 17:00:20 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:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:24 <openstack> The meeting name has been set to 'releaseteam'
17:00:32 <hberaud> #link https://etherpad.opendev.org/p/wallaby-relmgt-tracking Agenda
17:00:41 <hberaud> Ping list: ttx armstrong elod, damani
17:00:45 <armstrong> o/
17:00:49 <elod> o/
17:01:21 <damani> hi
17:01:44 <hberaud> We're way down on line 351 now.
17:02:03 <hberaud> Will just wait a couple minutes for folks.
17:02:11 <armstrong> ok
17:02:14 <damani> ok
17:02:52 <ttx> o/
17:03:30 <hberaud> I think we can go
17:03:35 <hberaud> #topic Review task completion
17:03:45 <hberaud> 1. Make sure the next development series name has been added to the data/series_status.yaml file
17:04:06 <hberaud> So we just need to push the merge button for
17:04:10 <hberaud> https://review.opendev.org/c/openstack/releases/+/772357/4
17:04:39 <hberaud> AFAIK nobody complained since our last communication about this
17:05:14 <hberaud> Any objection?
17:05:41 <armstrong> not from me
17:06:13 <hberaud> I just +W'd
17:06:45 <hberaud> so normally the next development series name will be added in few secondes
17:06:55 <hberaud> s/secondes/minutes
17:07:06 <elod> \o/
17:07:13 <hberaud> I think we can continue
17:07:18 <hberaud> 2) Need to reenqueue os-collect-config 11.0.2 and tripleo-ipsec 9.3.1
17:08:07 <hberaud> So we fungi tried to reenqueue the job unfortunately it didn't work as expected
17:09:14 <hberaud> I asked to the tripleo team if we could move tripleo-ipsec to indenpendent and they accepted
17:09:38 <hberaud> so now the both projects are independent
17:10:22 <hberaud> by doing this I think that we can ignore stable/ussuri
17:10:37 <ttx> yeah, I would just forget about those at this point
17:11:42 <hberaud> Notice that yesterday we found another project who meet the condition to trigger a similar problem https://review.opendev.org/c/openstack/releases/+/776215/
17:11:57 <fungi> yes, the other possible workarounds all have unpleasant and lasting side effects
17:12:40 <fungi> but also it sounds like it's a signal that a deliverable has stopped doing the stable branch model anyway
17:13:15 <hberaud> I started a discussion with marios about os-refresh-config and he will propose a branching for ussuri by searching for the right ancestor to use for the branch
17:13:42 <hberaud> IIRC os-refresh-config is already independent so maybe we can just ignore it now
17:14:27 <hberaud> anyway yesterday I proposed a patch to improve our checks and detect early similar issues https://review.opendev.org/c/openstack/releases/+/776206/5
17:14:36 <fungi> i suppose it's endemic to cycle-trailing deliverables because there's no process forcing them to make eventual releases?
17:14:45 <fungi> (final releases i mean)
17:14:53 <hberaud> hm good question
17:15:08 <fungi> we used to have a deadline
17:15:20 <hberaud> I started to write a tools to list all similar issues on all maintained branchees => https://review.opendev.org/c/openstack/releases/+/776496
17:15:32 <fungi> that was "relaxed" some years back, but is effectively uninforced
17:15:42 <fungi> er, unenforced
17:16:31 <hberaud> if all the listed project are trailing projects then I think we could say yes
17:16:38 <fungi> so the cycle-trailing deliverables are supposed to eventually make a final release for the cycle, but in reality they sometimes just never get around to it
17:16:47 <hberaud> I see
17:17:32 <fungi> and if that's happened up to the point where they want to tag a release for the next cycle, you easily get into this situation
17:17:55 <hberaud> I planned to add some process around the branching date to trigger the use of my tools so maybe we could trigger a run around the trailing deadline
17:18:29 <fungi> that sounds like a good idea, at least would give a better view of how large the problem is
17:18:43 <hberaud> I think it would enough to catch similar situation
17:19:42 <openstackgerrit> Merged openstack/releases master: Proposed release schedule for Xena (25w)  https://review.opendev.org/c/openstack/releases/+/772357
17:19:46 <hberaud> Anything to add about this task?
17:20:29 <openstackgerrit> Merged openstack/releases master: Add the wallaby cycle trailing date  https://review.opendev.org/c/openstack/releases/+/773454
17:21:09 <hberaud> xena have been added => https://opendev.org/openstack/releases/src/branch/master/data/series_status.yaml#L2-L7
17:21:14 <hberaud> Ok move on
17:21:25 <hberaud> #topic Assign R-7 tasks
17:21:58 <hberaud> Notify the Infrastructure team to generate an artifact signing key (but not replace the current one yet), and begin the attestation process.
17:22:03 <hberaud> Any volunteer?
17:22:43 <ttx> maybe we can consider it warned :)
17:22:54 <fungi> duly warned, thanks ;)
17:22:59 <hberaud> :)
17:23:04 <fungi> that's really a tact sig task now
17:23:31 <hberaud> ok so I skip this task in our tracking
17:23:49 <hberaud> Next one
17:23:57 <fungi> i added it to my todo list
17:23:58 <hberaud> Check with the Technical Committee to make sure Python runtimes have been determined for the next development cycle etc...
17:24:06 <hberaud> thanks fungi
17:24:14 <hberaud> Any volunteer for ^
17:25:13 <hberaud> Ok I take it
17:25:40 <hberaud> #topic Review countdown email contents
17:26:03 <hberaud> #link https://etherpad.opendev.org/p/relmgmt-weekly-emails
17:28:01 <hberaud> Concerning the project-specific events
17:28:10 <ttx> LGTM
17:28:19 <hberaud> I defined the cinder deadline to the friday
17:28:49 <hberaud> I don't think we want to use our week representation for specific events, isn't?
17:30:01 <ttx> not sure what you mean
17:30:09 <hberaud> I mean our weeks are from Thursday to Thursday
17:30:29 <hberaud> And they seems to use standard weeks
17:30:36 <hberaud> From monday to friday
17:31:02 <hberaud> So I keep the deadline for cinder on the friday of R-5
17:31:03 <ttx> hmm... maybe we should just simplify
17:31:12 <hberaud> However I made a mistake for oslo last week in my previous email, I gave Feb 25, so I prefered to keep the same date here
17:31:13 <ttx> but yes that will do for now
17:31:47 <hberaud> Anyway it's not an earth quake
17:32:08 <fungi> thursdays make good standard deadlines since there are often observed holidays on fridays
17:32:24 <fungi> and also less officially, people tend to just not be around as much on fridays
17:32:34 <ttx> yeah that was the original reason
17:32:57 <hberaud> Ok so I think we standardize this for all events in our calendar
17:32:57 <bnemec> Also, nobody likes dealing with a broken thing over the weekend. :-)
17:33:00 <fungi> the vmt also avoids publishing advisories on fridays, for the same reason
17:33:04 <ttx> "Fridays" are on Australian weekends
17:33:45 <hberaud> Next time I'll use Thursday even for project specific events
17:33:56 <hberaud> thanks for feedbacks
17:34:34 <hberaud> #topic os-refresh-config branching
17:34:59 <hberaud> We already discussed about this previously so I think that we can skip that point
17:35:08 <hberaud> nothing much to add here
17:35:35 <ttx> ++
17:35:38 <hberaud> #topic Open Floor
17:35:53 <hberaud> Anything else to discuss today?
17:35:58 * hberaud yes!
17:37:17 * fungi takes off tact sig hat, dons security sig hat
17:37:20 <fungi> i sent a bunch of project-focused requests to clean up public reports of suspected vulnerabilities... figure i'd mention it here as this is a good time in the cycle to try to check that you're not on track to release with unfixed known vulnerabilities
17:38:29 <fungi> the teams with impacted deliverables were glance, horizon, keystone, neutron, nova, oslo and swift... oslo has already cleaned up theirs in the hours since
17:38:50 <hberaud> fungi: is the PyYAML 5.1 is considered as a CVE?
17:39:05 <hberaud> I seen that bnemec proposed a related fix on oslo
17:39:25 <fungi> no, the vmt would consider that a class c2 report according to our taxonomy
17:39:28 <bnemec> I think it was a CVE on PyYAML. It shouldn't be on us.
17:39:39 <fungi> #link https://security.openstack.org/vmt-process.html#incident-report-taxonomy
17:39:50 <fungi> "A vulnerability, but not in OpenStack supported code, e.g., in a dependency"
17:40:13 <hberaud> Ok I see
17:40:47 <fungi> i'll comment in that bug shortly, just been in a series of meetings all morning
17:41:09 <hberaud> So we need diligent reviews
17:41:36 <fungi> i'm betting a lot of them can just be closed as already fixed or no longer relevant, but need feedback from the right teams to confirm
17:41:53 <hberaud> thanks for the heads up
17:42:52 <hberaud> Anything else?
17:44:03 <hberaud> I need a bash expert... does someone have an idea why my grep command here is surrounded by quotes during execution? https://review.opendev.org/c/openstack/releases/+/776496/1/tools/list_unbranched_projects.sh#1 line 64
17:44:04 * fungi takes off security sig hat, puts on martian antennae and green facepaint for landing party
17:44:20 <hberaud> :)
17:45:22 <fungi> is "serie" a typo?
17:45:23 <hberaud> When I run it single quotes are appends around the path
17:45:31 <hberaud> yes and no
17:45:46 <fungi> oh, i see it's defined that way so i guess not
17:45:58 <hberaud> I'll rename it current_series
17:47:01 <fungi> the series=($(list-maintained-series)) definition seems strange... any reason why that's being done in a subshell?
17:47:51 <hberaud> no, no specifc reasons
17:48:27 <hberaud> I just want to transform the output to an array
17:48:48 <fungi> anyway, i'm guessing te array elements in series are already wrapped in quotes when they're passed to the loop
17:49:23 <hberaud> hm the problem isn't ${serie}
17:49:53 <fungi> it might have to do with how output from list-maintained-series is formatted
17:50:08 <hberaud> the problem is that `grep -L "stable/${serie}" deliverables/${serie}/*.yaml` is tranformed into `grep -L "stable/${serie}" 'deliverables/${serie}/*.yaml'`
17:50:48 <fungi> also in your grep there, if you're wrapping one argument in "quotes" i'd do both arguments the same way, they both contain variable substitutions
17:50:53 <hberaud> by example for wallaby it will produce:
17:50:56 <hberaud> `grep -L stable/wallaby 'deliverables/wallaby/*.yaml'`
17:51:22 <hberaud> I see
17:51:37 <fungi> bash might be getting defensive
17:51:56 <fungi> try it with "deliverables/${serie}/*.yaml"
17:52:35 <hberaud> yes and as I'm using zsh I add an inception layer locally
17:52:37 <fungi> "quotes" still allow variable substitution and shell expansion while 'quotes' do not
17:53:35 <hberaud> I tried with "deliv...${serie}/*.yaml" and that didn't fixed my issue
17:54:13 <fungi> mm, so that wasn't the (only) reason, but you should keep the quotes anyway for safety
17:54:23 <hberaud> Ok I'll
17:55:00 <hberaud> Thanks for your comments fungi
17:55:51 <fungi> i guess list-maintained-series is another script in the same repo/directory just not added by that change?
17:56:07 <hberaud> yes this is a python script
17:56:17 <hberaud> in openstack_release
17:56:18 <fungi> oh, yeah i see the entrypoint in setup.cfg now
17:58:02 <ttx> got to run
17:58:09 <ttx> thanks hberaud !
17:58:13 <hberaud> I close the meeting, we can continue this discussion after if needed
17:58:19 <fungi> happy to
17:58:25 <fungi> i'll test it locally
17:58:41 <hberaud> thanks
17:58:45 <hberaud> thanks everyone
17:58:53 <hberaud> Just a final word...
17:59:38 <hberaud> I'm on PTO from tomorrow to Monday March the 1st
17:59:55 <fungi> i hope it's for something fun!
18:00:29 <hberaud> So limited availability on my side (FYI elod ttx ^)
18:00:41 <hberaud> #endmeeting