Friday, 2020-06-12

*** tetsuro has joined #openstack-release00:15
*** tetsuro has quit IRC00:17
*** armax has quit IRC00:18
*** tetsuro has joined #openstack-release00:22
*** coreycb has quit IRC01:12
*** mnasiadka has quit IRC01:19
*** mnasiadka has joined #openstack-release01:22
*** coreycb has joined #openstack-release01:23
*** ricolin has joined #openstack-release02:41
*** tetsuro has quit IRC03:38
*** tetsuro has joined #openstack-release03:38
*** prometheanfire has quit IRC04:28
*** evrardjp has quit IRC04:33
*** evrardjp has joined #openstack-release04:33
*** lifeless has quit IRC04:47
*** lifeless has joined #openstack-release04:48
*** prometheanfire has joined #openstack-release04:49
*** jtomasek has joined #openstack-release04:51
*** prometheanfire has quit IRC05:05
*** prometheanfire has joined #openstack-release05:15
*** vishalmanchanda has joined #openstack-release05:37
openstackgerritMichael Johnson proposed openstack/releases master: Release Octavia stable/stein 4.1.2  https://review.opendev.org/73528705:57
*** dustinc has quit IRC06:02
*** e0ne has quit IRC06:11
*** rakhmerov has quit IRC06:12
*** slaweq has joined #openstack-release07:05
*** slaweq has quit IRC07:10
*** e0ne has joined #openstack-release07:56
*** e0ne has quit IRC07:58
*** slaweq has joined #openstack-release07:58
*** e0ne has joined #openstack-release07:58
*** tosky has joined #openstack-release08:04
*** slaweq has quit IRC08:22
*** tkajinam has quit IRC08:23
*** slaweq has joined #openstack-release08:28
*** slaweq has quit IRC08:32
*** ianychoi__ has quit IRC08:38
*** tetsuro has quit IRC08:43
*** elod has quit IRC08:57
*** elod has joined #openstack-release09:03
elodsmcginnis: now that Octavia is EoL in Pike and Ocata, shouldn't periodic jobs disappear on that branches? :-o09:04
elode.g. http://lists.openstack.org/pipermail/openstack-stable-maint/2020-June/020385.html09:04
*** jtomasek has quit IRC09:12
*** priteau has joined #openstack-release09:14
*** e0ne_ has joined #openstack-release09:16
*** e0ne has quit IRC09:16
ttxsmcginnis: decided to drop the idea of a single model -- at this point I think the simplification gains are not worth disrupting our processes and toolchain09:17
ttxI'll still try to reduce the choices and where "independent" can be picked though09:18
ttxalso might pursue reimplementing cycle-trailing and cycle-automatic as variants of the main two. Like we could have with-rc/coordinated with-rc/trailing with-intermediary/non-client-library with-intermediary/client-library with-intermediary/coordinated with-intermediary/coordinated-automatic and with-intermediary/trailing09:22
ttxleft part describes how you use release version numbers, second part describes which deadlines apply to you09:22
ttxcurrently the deadline is implicit based on a number of other parameters. Making it explicit would help I think09:27
*** priteau has quit IRC09:39
*** priteau has joined #openstack-release09:41
*** e0ne has joined #openstack-release09:49
*** e0ne_ has quit IRC09:49
*** vishalmanchanda has quit IRC10:19
*** e0ne has quit IRC10:33
smcginnisttx: I like that.11:30
smcginnisttx: If we can at least collapse some of them, I think that's good.11:31
smcginnisttx: It was worth bringing up the idea. There seemed to be some support for it. I was a little concerned about how much work it was going to take us to rework a lot of our automation, but we would have gotten it done.11:32
smcginnisIt may be one of those ideas that needs to be pitched again in 6 months to a year once things have been able to sink in or things have changed enough to make it make more sense.11:32
smcginniselod: I think as long as the stable branch exists, it's going to try to run those jobs on it.11:33
smcginniselod: They need to have the branch deleted by infra. I asked in the reviews. But I guess we really need a process written down somewhere to cover all the steps needed when going to EOL.11:34
smcginnisIt's not just a release team thing. So maybe in the project team guide or something.11:34
smcginnisLike maybe https://docs.openstack.org/project-team-guide/stable-branches.html11:35
elodsmcginnis: we have the steps here https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-life and I can add extra steps there if needed :)11:47
smcginniselod: Oh yeah. Looks like that list can just be expanded. Probably link to an example review like this last one that does the eol tagging, then one more step of requesting the infra team delete the stable/* branch.11:49
elodI was thinking whether we need the deletion at all. or could it be enough if just the .zuul.yaml gets deleted11:49
smcginnisI *think* that's all that's needed then.11:49
smcginniselod: I think it's the presense of the stable branch that triggers that job, not that there is a zuul.yaml config in the branch.11:50
elodyes, but if we don't have .zuul.yaml, then there's no periodic job either :] so zuul won't pick that branch up11:51
elod(in octavia's case, it's zuul.d instead of .zuul.yaml https://opendev.org/openstack/octavia/src/branch/stable/ocata/zuul.d/projects.yaml#L6 )11:53
smcginniselod: Hmm, yeah, looking at how that's done, maybe.11:53
elodanyway, if the branch needs to be deleted, then it doesn't matter11:53
smcginnisBut really the branch needs to be deleted yet, so it would just be a temporary step to modify zuul.yaml at this point.11:53
smcginnisjohnsom: Did someone request the EOL stable branches be deleted for octavia?11:54
elodok, then it doesn't matter. I'll push a patch to add the next step with 'ask infra to delete the eol'd branch'. Thanks for the clarification smcginnis ! \o/11:56
smcginniselod: Thanks for working on that! :)11:56
*** e0ne has joined #openstack-release12:13
*** e0ne has quit IRC12:17
*** ricolin has quit IRC12:19
openstackgerritThierry Carrez proposed openstack/releases master: Cleanup old independent releases  https://review.opendev.org/73533012:22
*** e0ne has joined #openstack-release12:27
ttxsmcginnis: to clarify regarding cycle-trailing, I think it should be comparable to libraries. It's following the cycle, but with a specific deadline. For libraries we don;t have cycle-but-five-weeks-before, we just reuse c-w-i with type:library. So for cycle-trailing we could reuse c-w-rc or c-w-i (depending on whether they actually use rcs) with type:deployment-tool.12:34
ttxThat would remove a lot of hoops the automation has to jump through.12:35
ttxIf that sounds like a not-totally-stupid idea, I'll propose a change to do that. It should be invisible for users12:36
ttx(by users I mean developers wanting to do releases)12:36
openstackgerritThierry Carrez proposed openstack/releases master: Cleanup old independent releases  https://review.opendev.org/73533012:45
openstackgerritThierry Carrez proposed openstack/releases master: Cleanup old independent releases  https://review.opendev.org/73533012:55
smcginnisttx: I like that idea!13:05
ttxsmcginnis: that way we clearly differentiate "how releases are numbered" (release-model) and "what is it and when is the deadline" (type)13:09
smcginnisI think that's a good separation.13:09
ttxwill allow to get rid of the "if model=trailing then type=deployment" code that glues things together currently13:09
ttxalso will allow to actually track if the trailing thing uses RCs or not, and apply the right validation13:10
ttxcurrently it's a bit of a "whatever" zone13:10
smcginnisLooking at some of the release generation automation, I think that will help pull the right set of deliverables at different phases too.13:10
ttxand finally will allow to reword docs in a way that actually makes sense13:10
smcginnisSo maybe not the major simplification you were originally thinking, but at least simpler than it was. ;)13:11
ttxwell I might not be able to get it down to 2 models, but 3.13:11
ttxOnce I'm done with =trailing, I'll replace cycle-automatic by a new guideline field that tells us what we are allowed to do as relmgt team13:12
ttx(doing one automatic release at the end would be one of those potential guidelines)13:13
ttxit does not need a "release model"13:13
ttxjust a hint13:14
smcginniscycle-automatic really has evolved to be c-w-i with the addition of the expectation that we will propose the final release.13:15
smcginnisWhich actually gets a little more blurred since we've started proposing other releases for unreleased commits, but still is clear that we will tag it whether it has changes or not.13:15
openstackgerritThierry Carrez proposed openstack/releases master: Rally is a service  https://review.opendev.org/73533713:23
*** vishalmanchanda has joined #openstack-release13:41
*** armax has joined #openstack-release14:22
*** jtomasek has joined #openstack-release15:16
*** jtomasek has quit IRC15:37
*** jtomasek has joined #openstack-release15:40
*** armax has quit IRC16:02
*** jtomasek has quit IRC16:05
openstackgerritMonty Taylor proposed openstack/releases master: Release 2.2.0 of osc-lib  https://review.opendev.org/73536716:06
*** armax has joined #openstack-release16:18
openstackgerritMerged openstack/releases master: Release 2.2.0 of osc-lib  https://review.opendev.org/73536716:35
*** armstrong_ has joined #openstack-release16:58
armstrong_Hello @smcginnis some mailing-list addresses were deleted/merged. Was the release team mailing-list affected?17:02
smcginnisarmstrong_: Where did you see that? I don't think we've been affected. We use openstack-discuss and release-announce.17:07
smcginnisAnd release-job-failures. They're all still listed in the mailman list: http://lists.openstack.org/cgi-bin/mailman/listinfo17:07
armstrong_ok thanks, I read a mail from @fungi concerning some mailing-list that he wanted to merge17:09
fungiit was about closing the user-committee mailing list and directing further discussion about openstack user committee activities to the openstack-discuss mailing list17:15
funginothing to do with the release-failures mailing list17:15
armstrong_ok fungi thanks for the clarifications17:16
fungiyou're welcome!17:20
*** diablo_rojo has joined #openstack-release17:41
johnsomsmcginnis I just asked in the OpenDev channel, but it sounds like the release team can remove those branches as well?17:46
smcginnisjohnsom: I don't think any of us have that power. Well, maybe ttx, but typically not.17:50
johnsomsmcginnis fungi is on it for us.17:51
smcginnis++17:51
fungithe way we've sometimes done it is to add a volunteer temporarily to a group which has project owner permission (a blanket permission required to have access to delete branches in the version of gerrit we're currently on)17:56
fungibut if it's just a handful of deletions like this, it's not hard for me to just knock out17:57
fungithere's been times where we had 40+ branch deletions to do, and double-checking those can be time consuming17:58
*** jtomasek has joined #openstack-release18:01
*** jtomasek has quit IRC18:03
*** jtomasek has joined #openstack-release18:05
smcginnisfungi: We'll probably have more now that some of the EM branches are getting older.18:05
smcginnisfungi: I wonder if would make sense to add some sort of flag to something like here: https://opendev.org/openstack/releases/src/branch/master/deliverables/newton/barbican.yaml#L818:06
*** priteau has quit IRC18:06
*** jtomasek has quit IRC18:06
smcginnisWhere we could have something like "branch-status: deleted" and that would trigger our automation to remove the branch if it is found.18:06
smcginnisSo at the same time someone proposes something like an ocata-eol tag, they can also add that flag and it just takes care of everything.18:07
*** jtomasek has joined #openstack-release18:07
*** jtomasek has quit IRC18:10
*** jtomasek has joined #openstack-release18:16
*** jtomasek has quit IRC18:16
fungiyeah, maybe, once we're on newer gerrit and can grant branch deletion permission safely to the account the job is using18:18
fungihopefully only a few weeks out at this point18:18
smcginnisOh great.18:25
*** irclogbot_3 has quit IRC18:29
*** irclogbot_2 has joined #openstack-release18:33
*** e0ne_ has joined #openstack-release19:08
*** e0ne has quit IRC19:08
*** diablo_rojo has quit IRC19:24
*** vishalmanchanda has quit IRC19:51
*** e0ne_ has quit IRC20:49
-openstackstatus- NOTICE: The Gerrit service on review.opendev.org is going offline momentarily at 21:00 UTC for project rename maintenance, but should return within a few minutes: http://lists.opendev.org/pipermail/service-announce/2020-June/000004.html20:57
*** armstrong_ has quit IRC21:13
-openstackstatus- NOTICE: gerrit is being taken offline for emergency cleanup, will return to service again shortly21:59
-openstackstatus- NOTICE: The Gerrit service on review.opendev.org is available again22:49
*** tosky has quit IRC23:25
*** armax has quit IRC23:52

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