15:00:28 #startmeeting tc 15:00:28 Meeting started Thu Jul 14 15:00:28 2022 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:28 The meeting name has been set to 'tc' 15:00:33 #topic Roll call 15:00:33 /o 15:00:38 o/ 15:01:03 o/ 15:01:04 slaweq and arne_wiebalck informed about their absence in today meeting 15:01:26 I will be out next week, btw. :-) 15:01:44 o/ 15:01:58 jungleboyj: ack 15:02:06 let's start 15:02:08 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting 15:02:20 today agenda ^^ not much topic so may be it will be quick 15:02:32 #topic Follow up on past action items 15:02:43 rosmaita to send the email on openstack-discuss and community (local user groups ML) about asking who need translation 15:02:55 yeah, still working on that 15:02:59 o/ 15:03:05 rosmaita: ack. 15:03:18 i have some questions, will wait for open discussion 15:03:31 rosmaita: ok sure 15:03:53 gmann to ask about Adjutant maintainer on ML and start the next step of retirement or adding it in In-active project list. 15:04:01 I sent and we have PTL volutneer also 15:04:02 #link https://lists.openstack.org/pipermail/openstack-discuss/2022-July/029514.html 15:04:18 #link https://review.opendev.org/c/openstack/governance/+/849606 15:05:01 \o/ 15:05:06 please review the PTL nomination patch 15:05:12 gmann to remove this(environmental SIG proposal) from agenda and we will check feedback on review or ML 15:05:15 that is also done 15:05:36 #topic Gate health check 15:05:57 one update is about centos stream 9 testing stability 15:06:36 centos stream maintainer joined our previous week meeting and we discussed few of the things, I sent the summary of discussion on ML #link https://lists.openstack.org/pipermail/openstack-discuss/2022-July/029468.html 15:07:44 let's see if communication improve in both way but it was clear that we both community needs to debug the failure together, expecting centos stream alone doing that is difficult for them as per devstack/tempest and failure debugging knowledge 15:08:13 not sure what else we can do on this then triage the failure at openstack side first and then report to them 15:08:47 and when to make to voting as new issue can come at any time due to nature of latest version deps in centos stream 15:09:27 I think we just need to keep these periodic 15:09:30 keeping it non voting make failure gets ignored and making it voting impact our development progress 15:09:57 unless they're going to change their workflow (which is the point of stream to begin with) I don't see how we can be voting on it 15:10:12 yeah 15:10:18 even if they triage and fix bugs very quick, we can't stall pipelines for 24 hours, which is realistically about as fast as it could be 15:10:28 I also think periodic is best possible way here 15:10:34 true 15:11:07 does anyone have an understanding of why ubuntu-based jobs are more stable than centos? 15:11:16 because the things they put in are tested 15:11:21 in QA office hour and I am sure other projects also, we monitor periodic job results 15:11:21 stream things are not, that's the point 15:11:43 yeah stream is kind of testing *next* things 15:11:55 we test on released ubuntu, which means it has been tested 15:12:20 stream is like testing on bare upstream trees for the most part 15:12:48 :-( 15:13:25 i thought it was supposed to be "mostly tested" 15:13:34 We can definitely put out an invite but maybe with an idea of what time they’re needed 15:14:25 rosmaita: not that I know of.. at least one situation before came because they were putting things into stream *so* they could test them, not *because* they had tested it 15:14:28 rosmaita: texsted at some level but not with all things deps latest version like openstack tested libvirt version 15:15:08 so realistically, it doesn't seem like a suitable distro to use as the basis for our CI 15:15:09 they put libvirt new version but how it will be working with OpenStack or any other usage is not well tested 15:15:11 "tested at some level" meaning it might have passed libvirt project testing, because it landed there 15:15:15 rosmaita: right that's my point 15:15:21 yeah 15:15:57 in that case we can test it periodic but keep it in our testing runtime so that we have python version testing at least which are compatible to them 15:16:42 right 15:16:47 any objection of making it periodic with experimental pipeline(on demand run) ? 15:16:48 well, periodic would be less waste of resources than having it nonvoting 15:16:53 yeah 15:16:59 but i don't know that anyone will pay attention to it 15:17:02 I also think periodic is less likely to be ignored than non-voting 15:17:04 and we will have enough data for failure 15:17:09 nv failures are basically just waste, IMHO 15:17:12 dansmith: true 15:17:37 rosmaita: in QA we do monitor all periodic job in QA projects weekly basis 15:17:54 rosmaita: That sounds like it might be a better approach then. 15:17:58 I think many other project might be doing the same. but checking periodic jobs in weekly meeting is good way 15:18:07 ++ 15:18:13 I think periodic also has more chance of being statistically stable, so noticing going from 95% pass to 100% fail is easier 15:18:25 n-v jobs failing can be because of the patch not being finished, etc 15:18:53 yeah 15:19:03 this sounds like a good plan to me, then 15:19:21 Makes sense to me. 15:19:41 cool 15:20:14 right, periodic jobs are testing changes which have already merged, so rules out broken changes (unless the changes themselves are suddenly introducing incompatibilities for centos) 15:21:00 #agree to make centos stream jobs testing in periodic way but keep it in testing runtime. monitor, debug, and report the failure to centos stream team 15:21:21 any other news on gate health ? 15:22:11 gmann: you can make this change in the zed template? 15:22:49 rosmaita: yeah, we can and remove it from non voting also which are in project side mostly 15:23:18 we are not stopping testing but testing in a most feasible way 15:23:24 right 15:23:28 so should be ok to do change in zed cycle 15:23:36 ok 15:24:09 if nothing else, moving to next topic? 15:24:20 #topic RBAC community-wide goal 15:24:23 #link https://review.opendev.org/c/openstack/governance/+/847418 15:24:37 patch is up, thanks dansmith rosmaita for review 15:24:56 nothing else on this than other tc-members please review it as we are already late in zed cycle 15:25:16 unless there is any question anyone want to discuss here 15:26:26 ok moving next 15:26:46 #topic Open Reviews 15:26:48 #link https://review.opendev.org/q/projects:openstack/governance+is:open 15:27:13 this is one patch to review other than we already discussed #link https://review.opendev.org/c/openstack/governance/+/849155 15:27:23 adding skyline in emerging technology list 15:27:26 that is all 15:27:38 rosmaita: please go ahead on i18 SIG things 15:28:28 oh, ok 15:28:50 my question is whether anyone has a suggestion for a survey tool that is accessible in china 15:28:57 or, whether that's not a concern 15:29:19 i've used wufoo, but the free version is very limited 15:30:19 no sure, may be we can ask ricolin about it 15:31:16 ok, i will email him 15:31:23 Open infra day asia might be good place to inform about that survey also. it is schedule on July 22-23. ricolin is one of the organizer of it 15:31:54 thanks for that suggestion 15:32:15 it include most of the group of asia which are/were using translation including this SIG mainatiner ianychoi[m] 15:33:03 it's helpful to have a deadline 15:34:06 may be if some usage data we can get within zed cycle so that in 2023.1 we can take some decision ? 15:35:09 yep 15:35:53 ok, anything else on this topic? 15:36:07 nope 15:36:19 ok, thanks rosmaita for working on it 15:36:27 that is all from today meeting. 15:36:29 np, now i will work faster 15:36:35 thanks 15:36:53 let's close the meeting. thanks all for joining 15:37:01 #endmeeting