16:00:01 <smcginnis> #startmeeting releaseteam
16:00:02 <openstack> Meeting started Thu May 14 16:00:01 2020 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:05 <openstack> The meeting name has been set to 'releaseteam'
16:00:16 <smcginnis> Ping list: ttx armstrong diablo_rojo, diablo_rojo_phon
16:00:23 <smcginnis> #link https://etherpad.opendev.org/p/ussuri-relmgt-tracking Agenda
16:00:25 <diablo_rojo> o/
16:00:54 <hberaud> o/
16:01:13 <ttx> o/
16:01:26 <smcginnis> Thanks everyone for a successful Ussuri release.
16:01:29 <fungi> congrats!
16:01:41 <ttx> woohoo!
16:01:46 <smcginnis> #topic Release postmortem
16:01:46 <ttx> Come celebrate tomorrow!
16:01:54 <ttx> that should be quick
16:02:00 <diablo_rojo> thank you for doing all the legwork yesterday!
16:02:04 <ttx> The only thing in my bucket list is:
16:02:06 <hberaud> \o/
16:02:07 <diablo_rojo> Seemed to go smoothly.
16:02:15 <ttx> "During a routine check, list-deliverables --no-stable-branch --series ussuri --cycle-based-no-trailing reported "patrole" while it has stable-branch-type: none"
16:02:39 <smcginnis> That's really it. I think the last week or two went really smooth.
16:02:45 <ttx> we'll need to fix list-deliverables so that in that case it ignores the things that do not used versioned releases
16:02:53 <smcginnis> Not to jinx victoria, but I think this was the smoothest release yet.
16:03:25 <smcginnis> Should be a pretty easy fix to list-deliverables.
16:03:41 <diablo_rojo> Lol yes, please no jinxing
16:03:48 <ttx> I'll leave it to someone who wants to disocver the codebase there
16:03:55 <openstackgerrit> Merged openstack/releases master: Update missing cmd to follow redirects  https://review.opendev.org/727733
16:03:57 <openstackgerrit> Merged openstack/releases master: Update release week process  https://review.opendev.org/727748
16:04:09 <fungi> watching the release tagging, we noticed the job was not taking advantage of the local repo cache on the node due to an outdated path, so smcginnis pushed a fix
16:04:13 <ttx> diablo_rojo: what time is the celebration tomorrow?
16:04:41 <smcginnis> fungi: And ttx just approved it, so we should see that merge notice popping up here shortly!
16:05:01 <smcginnis> That will make it even better. A slight performance improvement at least.
16:05:12 <evrardjp> congrats everyone
16:05:29 <smcginnis> fungi: Is there a zuul restart planned yet? There was some talk of a reconfigure improvement on tagging.
16:05:34 <diablo_rojo> 20 UTC
16:05:53 <openstackgerrit> Merged openstack/releases master: Use updated git cache dir default path  https://review.opendev.org/727710
16:05:55 <openstackgerrit> Merged openstack/releases master: Release reno 3.1.0  https://review.opendev.org/724697
16:05:56 <openstackgerrit> Merged openstack/releases master: Release puppet-ceph 3.1.1  https://review.opendev.org/727094
16:05:59 <smcginnis> And there we go ^^
16:06:27 <smcginnis> Celebration info:
16:06:30 <smcginnis> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014781.html
16:07:21 <smcginnis> So back on topic, if someone wants to take a look at list-deliverables, it shouldn't be too difficult and might be a good way to get a little experience with that code.
16:07:36 <hberaud> go
16:07:39 <smcginnis> Otherwise I'm sure one of us can get to it in the near future.
16:07:44 <hberaud> I'm volunteer
16:07:46 <evrardjp> hberaud: that's python, sorry
16:07:47 <fungi> smcginnis: yes, some time today i believe
16:07:52 <smcginnis> hberaud: Thanks!
16:07:53 <evrardjp> hberaud: cool
16:07:57 <evrardjp> :)
16:08:01 <smcginnis> and.. fungi: Thanks!
16:08:21 <smcginnis> Anything else on a Ussuri postmortem?
16:08:44 <smcginnis> #topic Review next week tasks
16:08:48 <fungi> smcginnis: in related zuul+tags news, a couple months ago the branch guessing change for tags merged to zuul, so we might be able to move or rework some tag-related jobs now that zuul can associate those with a branch
16:08:48 <smcginnis> Speaking of which...
16:09:00 <smcginnis> fungi: ++
16:09:16 <smcginnis> Starting next week, we will now switch over to the victoria etherpad..
16:09:19 <smcginnis> #link https://etherpad.opendev.org/p/victoria-relmgt-tracking
16:09:37 <smcginnis> Task 1 - Initialize victoria deliverables once final ussuri has been completed and cleaned up
16:09:54 <smcginnis> I think we have a few deliverables that have been carried over without much activity.
16:10:07 <ttx> I did copy the tasks up until victoria-1
16:10:15 <smcginnis> We may want to take a closer look at some of those to figure out if any of the deliverable files should be dropped.
16:10:26 <smcginnis> Thanks for doing that ttx. As usual, you beat me to it. :)
16:11:23 <smcginnis> I will put my name down for getting the deliverable files set up, but if anyone ends up bored with some free time, feel free to grab it.
16:11:38 <smcginnis> Task 2: Swap out ussuri signing key for victoria
16:11:47 <smcginnis> I think that one is for you fungi.
16:11:57 <smcginnis> Or at least, someone on the infra team.
16:12:26 <fungi> yeah, i'm behind on that
16:12:30 <smcginnis> #link https://docs.openstack.org/infra/system-config/signing.html
16:12:33 <fungi> but will bump it up my priority list
16:12:53 <smcginnis> We probably have a little leeway before somoene asks for a victoria release, but could happen.
16:13:15 <smcginnis> Task 3: Email all PTLs and liaisons
16:13:45 <smcginnis> I will try to get that done early next week. We have a few newer PTLs, so would be good to make sure they are aware of the release process.
16:13:48 * hberaud just rebooted...
16:14:06 <smcginnis> Welcome back. :)
16:14:15 <hberaud> lol
16:14:30 <smcginnis> And I will send the countdown email.
16:14:44 <smcginnis> Last thing regarding next week - should be slow, so no need for a meeting.
16:14:59 <hberaud> sorry for my late response but I can manage some items if needed
16:14:59 <smcginnis> So you all get an extra hour next week. :)
16:15:06 <diablo_rojo> Makes sense to me
16:15:12 <smcginnis> Thanks hberaud
16:15:30 <smcginnis> #topic Ironic release model change
16:15:40 <smcginnis> #link https://review.opendev.org/#/c/725547/
16:15:58 <smcginnis> I have this up and read part way through, but need to find a block to focus on it and think it through.
16:16:16 <smcginnis> If it's just a matter of more releases and more stable branches, I think we can support that.
16:16:42 <smcginnis> We have some validation checks to make sure branch names conform to our expectations, so we probably need to update how that works.
16:16:59 <smcginnis> But the proposal looked sane as far as versioning with semver between releases, etc.
16:17:14 <smcginnis> ttx: Did you get a chance to digest the proposal?
16:17:37 <ttx> yeah my two questions I posted on the meeting etherpad
16:17:50 <ttx> Like do we expect any issue with extra branches
16:18:03 <ttx> would they pass validation, would we handle them
16:18:21 <ttx> and could we support branch aliases (git symbolic-ref) to link numbers with names ?
16:18:55 <ttx> (allowing them to have stable/16.x -> stable/victoria)
16:19:26 <smcginnis> I haven't used symbolic-ref. I wonder if that would allow branch selection in gitea and GitHub or if it would have an issue that would cause confusion.
16:19:37 <smcginnis> We can try with release-test.
16:20:44 <smcginnis> I suppose the advantage is less cruft in the git history?
16:21:25 <ttx> they raised the issue of having mixed naming used
16:21:48 <ttx> 15.x 16.x victoria 18.x ...
16:22:01 <smcginnis> Maybe not as efficient, but we could have two branches off of the same commit, right?
16:22:23 <ttx> smcginnis: you would not commit backports to both I suspect
16:22:24 <fungi> symbolic refs do you mean lightweight tags?
16:22:35 <ttx> no I mean git symbolic-ref
16:22:41 <fungi> ahh
16:23:34 <fungi> okay, so like the named refs gerrit uses to identify changes
16:23:47 <fungi> (in its refs/changes tree)
16:23:58 <ttx> fungi: probably. It's just a file that points to another ref
16:24:09 <smcginnis> I'm not finding a good explanation of symbolic-refs I guess. Looks like just referring to things like HEAD. So I guess it's a matter of creating a name like HEAD and having that point at the branch?
16:24:25 <ttx> yes
16:24:30 <ttx> HEAD is a symbolic-ref
16:24:52 <smcginnis> The other question too is whether dulwich supports it.
16:25:23 <ttx> smcginnis: do we need it to support it? Or would we run only on the "real" branches
16:25:37 <ttx> stable/victoria would be the real thing
16:25:51 <ttx> stable/18.x would redirect humans to it
16:25:57 <smcginnis> I guess we would have to test. Some of our validation code uses dulwich, so I would just want to make sure it doesn't cause any problems for that.
16:26:31 <ttx> yes, needs testing
16:27:07 <smcginnis> It's worth investigating. Otherwise a backport to victoria would need to be cherry-picked to both stable/victoria and stable/18.x.
16:27:20 <smcginnis> So if we can get it set up to just be one real branch, that helps a lot.
16:27:29 <ttx> which would be extremely dangerous
16:27:50 <ttx> if you miss one it would be very hard to detect
16:27:59 <smcginnis> Yeah, very prone to human error.
16:28:17 <ttx> probably simpler to maintain a hole in the stable/xx.x numbering
16:28:25 <ttx> if symbolic refs don;t work
16:30:31 <smcginnis> On the plus side, at least from my limit understanding so far, this seems to be the only challenging part about their proposal.
16:30:58 <ttx> yeah
16:31:03 <ttx> the rest would just work imho
16:31:51 <smcginnis> We should make sure they are aware they are signing up for a lot of stable branch maintenance work if they will be branching every other month.
16:32:29 <smcginnis> That means backporting a bugfix to stein becomes 10 patches instead of 4 (or something like that, just an example).
16:32:49 <diablo_rojo> Oof thats quite the inflation.
16:33:03 <fungi> are they planning to still use and be included in integrated testing with stable branches of other openstack projects? and if so, how are they planning to map their stable branches to them?
16:33:16 <smcginnis> Another good question.
16:33:41 <smcginnis> I would assume anything between ussuri and victoria would test against victoria code.
16:34:04 <ttx> yeah, we might want to point out the extra work to them... not sure they realize how crazy that is
16:34:06 <smcginnis> I didn't read far enough in the proposal yet to see if they've addressed that.
16:34:09 <fungi> for example, stable/ussuri change for nova kicks off a devstack job, which branch of ironic does that test against? or stable/x.y branch of ironic has a change, does it run a devstacl job which uses nova and is there a way to work out which nova branch it should use?
16:34:23 <ttx> fungi: I think those other branches would not get tested
16:34:39 <fungi> that can be done by manually associating each and every branch with branch-override options in zuul job configs, but it can get messy
16:34:50 <smcginnis> I was thinking testing from the ironic side. For other projects, I would expect them to just ignore these extra branches.
16:35:14 <fungi> and yes, if there are several ironic stable branches which map to stable/ussuri on the nova side, nova would probably pick only one of them to test against
16:35:26 <fungi> which also means depends-on and the like won't work
16:36:12 <smcginnis> That is a potential issue.
16:36:31 <ttx> fungi: would be great to point out the issues on that review, with an infra hat on
16:36:47 <ttx> I have no idea what level of testing they want
16:37:33 <fungi> i think what would happen if you had stable/10.11 and stable/10.12 branches for ironic and nova stable/ussuri wants to depends-on a change to ironic stable/10.11 but nova is configured to test stable/10.12 with ussuri instead, it will effectively test without the stable/10.11 change on which it declares that dependency
16:37:36 <AJaeger> didn't one of the telemetry projects had such a versioning - that was quite a mess in jobs?
16:37:53 <ttx> swift did that for a while, not sure if that was an issue
16:37:59 <smcginnis> And eventually led them to going outside OpenStack.
16:38:37 <fungi> AJaeger: yes, i think aodh or gnocchi did that with numbered stable branches mapped to named stable branches of other openstack projects, but it was just a 1:1 mapping if memory serves
16:39:13 <smcginnis> It would be good if folks can comment and raise these questions on that spec.
16:39:13 <fungi> (and it was a huge mess, but in part because of devstack-gate, may it forever rest in peace)
16:39:23 <AJaeger> might have been gnocchi - and I think they had more branches. Just remember many jobs with branch mappings in it ;(
16:39:38 <smcginnis> If we need to schedule a time to sync in realtime, we can probably try to get everyone together to talk through the issues.
16:41:54 <smcginnis> OK, I don't think we can solve anything here, but at least we've gotten some issues to think through.
16:42:06 <smcginnis> #topic Open Floor
16:42:17 <smcginnis> Any other topics to bring up while we're here?
16:42:40 <ttx> nope
16:42:44 <ttx> need to run actually
16:42:51 <diablo_rojo> Fun thing of note, the cloud provider sig decided that they were going to start doing versioning like the openstack cloud provider.
16:43:00 <diablo_rojo> I guess we are a poster child for versioning.
16:43:11 <smcginnis> Semver makes a lot of sense.
16:43:18 <diablo_rojo> They want all the other providers to start doing it the same way
16:43:29 <diablo_rojo> Theres a KEP up for review now
16:43:34 <diablo_rojo> But I think its pretty set.
16:43:35 <smcginnis> I wish I had semver.org to point to in some internal versioning discussions way back.
16:43:36 <diablo_rojo> So thats cool.
16:43:49 <smcginnis> Nice!
16:44:32 <diablo_rojo> Yeah :)
16:44:49 <smcginnis> OK, I think that's it for today.
16:44:56 <ttx> thanks smcginnis !
16:45:00 <diablo_rojo> Thanks smcginnis
16:45:03 <smcginnis> Thank you again everyone for a great cycle. On to the next one!
16:45:06 <diablo_rojo> thanks everyone for another release!
16:45:14 <smcginnis> #endmeeting