14:04:07 #startmeeting releaseteam 14:04:07 Meeting started Fri Jan 6 14:04:07 2023 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:04:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:04:07 The meeting name has been set to 'releaseteam' 14:04:14 o/ 14:04:20 o/ 14:04:25 Ping list: hberaud armstrong elodilles 14:04:47 #topic Review task completion 14:05:03 Generate a list of all cycle-with-intermediary libraries which did not release since the 2022-11-16 date of milestone-1 (hberaud) 14:05:39 #link https://review.opendev.org/q/topic:antelope-milestone-2 14:05:59 glance declined our release patch https://review.opendev.org/c/openstack/releases/+/869059 14:06:14 I think we can abandon this one 14:06:21 any opinion? 14:06:29 ok for me 14:06:29 nope, let's abandon then 14:06:39 done 14:06:47 Fix upper constraint redirection ( https://releases.openstack.org/constraints/upper/2023.1 ) (elod) 14:06:56 and the only one remaining is the keystone patch 14:07:02 I think we can merge it 14:07:10 https://review.opendev.org/c/openstack/releases/+/869053 14:07:14 oh right sorry 14:07:21 np 14:07:44 Let's give it until Monday and we'll force it? 14:08:05 and maybe drop a message on the review to say so 14:08:11 as keyston is under DLP and if I remember correctly both voter are team members 14:08:22 sounds ok 14:08:25 ah ok then 14:08:41 I don't know why the badge was not added 14:09:03 ok, back to Fix upper constraint redirection ( https://releases.openstack.org/constraints/upper/2023.1 ) (elod) 14:10:05 sorry, i just started to look into the issue and don't have a solution yet for the redirection fix 14:10:30 here is the redirection added: https://opendev.org/openstack/releases/src/branch/master/doc/source/_templates/htaccess 14:10:44 so probably we need some kind of mapping... 14:10:54 antelope -> 2023.1 14:11:07 if you don't have better ideas 14:12:09 yeah that was the kind of issue I was expecting with not using the name in the branch 14:12:33 yepp 14:13:08 originally 2023.1 should have been used in the deliverables directory but that had problems in the beginning 14:13:22 instead of antelope 14:13:46 The constraint name is based on the directory name? 14:13:53 yes 14:14:29 i think it comes from here: https://opendev.org/openstack/releases/src/branch/master/openstack_releases/_redirections.py 14:15:07 so we can either create some form of mapping... or just say that the branches should be named stable/antelope after all 14:16:06 probably the mapping is not that hard, just needs to be decided where to put 14:16:28 I don't think we need to solve it today, right 14:16:42 anyway, I'll try to propose a patch early next week and we can discuss there 14:16:48 maybe we can open a thread to discuss it on the list and make sure we pick the right solution 14:17:01 since we may be overlooking something 14:17:17 and it's good that the TC knows that their numbering is creating all kinds of issues for us 14:17:54 TC was quite clear about they want 2023.1, so let's try that first :) 14:18:04 * stable/2023.1 14:18:19 right, and we said that might create issues 14:18:22 i take it "series" can me made to contain 2023.1 14:18:29 er, can't i mean 14:19:10 deliverables/2023.1 caused other issues 14:19:13 fungi: that would likely create a cascade of other issues 14:19:32 so far this one is the only we detected with the hybrid approach 14:19:32 what's building the _deliverables that gets passed into generate_constraints_redirections()? 14:22:02 we pass the _deliverables here: https://opendev.org/openstack/releases/src/branch/master/doc/source/_exts/deliverables.py#L517 14:22:10 looks like the series comes from here: https://opendev.org/openstack/releases/src/branch/master/openstack_releases/deliverable.py#L155 14:22:15 so somewhere in that file 14:22:30 it comes from loading up the deliverables directory content 14:22:40 so it's based on the directory names 14:22:52 yeah, glob.glob(os.path.join(root_dir, '*/*.yaml')) 14:23:18 so would require having the directory named 2023.1 i guess, in order to avoid remapping 14:23:32 so yeah, either mapping, or using numbres in dir names, or using names in branch names :) 14:23:46 :) 14:23:56 ok let's move that off-meeting 14:24:19 Catch if there are acl issues in newly created repositories (elod) 14:24:20 ++ 14:24:34 the aclissues.py reports issues with bifrost.config, ironic.config and ironic-inspector.config files 14:24:49 added by this patch: https://review.opendev.org/c/openstack/project-config/+/866937 14:24:59 to handle bugfix branches 14:25:08 for ironic team 14:25:15 so this is intentional 14:25:32 ok so it's not happy that we don;t have control 14:25:48 the script works as intended :) 14:25:51 we have control, but ironic team, too :) 14:25:57 ttx: yepp :) 14:26:13 so in short: nothing that is a real ACL issue :) 14:26:19 ok yeah we could update the script... or just keep it as-is as a reminder of that "exception" to the rule 14:26:35 yepp 14:27:05 anything more to discuss on that? 14:27:17 nope, i think 14:27:30 i mean: nothing else :) 14:28:51 Require a beta release for mistral and adjutant / intermediary releases then to doublecheck gates (elod) 14:29:01 ok 14:29:11 so, i've propsed: https://review.opendev.org/q/topic:inactive-release-test 14:29:22 beta & intermediary releases ^^^ 14:29:34 at least our validators are happy 14:30:08 it came up in #openstack-infra last week that zaqar may need similar care 14:30:37 it's apparently not merged any changes for months, and still has broken zuul job configuration in master 14:30:39 fungi: as I remember to zaqar's state, i'd say yes 14:31:23 as in, right now the only change that could merge to zaqar is the one to trivially fix their named gate queue, it's been sitting there unreviewed since something like september 14:33:43 fungi: was this topic on TC meeting as well? 14:34:10 i raised it on the tc channel on sunday 14:34:24 oh, i see, thanks for that! 14:34:26 i was unable to attend the tc video call this week, so not sure if it got raised there 14:34:37 :/ 14:35:14 Is there anything more to be done on this at this stage? 14:36:35 when the tc started their meeting, i reminded them that this week was the deadline to decide what projects would be included in 2023.1 so hopefully they considered those situations 14:38:28 we should probably reach out and see if there was anything specific decided 14:40:23 let's add that to next week's actions 14:40:43 oh, according to the TC meeting log they also has the action to ping me :) 14:40:51 so the circle is closed :) 14:41:02 ah lol 14:41:07 OK, let's add it to next week's action then 14:41:22 I passive-sensed it 14:41:28 :) 14:41:35 Alrigth, moving on 14:41:42 #topic Review countdown email 14:41:52 #link https://etherpad.opendev.org/p/relmgmt-weekly-emails 14:42:19 I prepared it, let me know if it looks good and I'll send it today 14:44:42 dates are OK 14:44:49 LGTM 14:45:16 (i somehow marked Feb 15 as client lib freeze but it should be Thursday, so 16 is the right date) 14:45:30 LGTM, too 14:45:49 okok 14:46:02 #topic Assign next week tasks 14:46:55 elodilles: the TC is likely to reach to you if that's what they have written down, so probably best if you cover that one 14:47:20 hberaud: I can take teh cycle planning if you don;t want it 14:47:41 ok thanks 14:47:52 ttx: ack, added my name to it 14:48:15 I'll just have to remember how to do it 14:48:43 #topic Open discussion 14:48:50 ttx: i can help to find the resources as I somehow managed it last occasions :) 14:50:51 I'll ask you if I don;t find my way 14:51:11 anything else, anyone? 14:51:58 i pinged the tc members in #openstack-tc again to remind them the release managers were hoping to hear a decision this week on adjutant/mistral (potentially also zaqar) 14:52:06 ( tools/list_weeks.py is the entry point, as it is mentioned in the process page) 14:53:34 alright, if nothing else... thanks everyone! 14:53:42 #endmeeting