| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-02 | |||
| 16:14:38 | dansmith | #vote yes, no | |
| 16:14:38 | opendevmeet | dansmith: yes, no is not a valid option. Valid options are , yes, no, . | |
| 16:14:41 | sean-k-mooney[m] | lets just assume we are ok with the 16th and move on | |
| 16:14:44 | dansmith | #vote yes, no, | |
| 16:14:44 | opendevmeet | dansmith: yes, no, is not a valid option. Valid options are , yes, no, . | |
| 16:14:45 | yuriys | this is bot abuse! | |
| 16:14:53 | bauzas | #endvote | |
| 16:14:53 | opendevmeet | Voted on "Spec review day proposal on Tuesday Nova 16th ?" Results are | |
| 16:14:53 | dansmith | #vote meh | |
| 16:14:55 | gibi | thet is fun | |
| 16:15:23 | bauzas | ok I guess this was epic but we should leave this bot quiet back for 5 years | |
| 16:15:38 | bauzas | anyway, | |
| 16:15:51 | bauzas | #agreed Spec review day happening on Nov 16th | |
| 16:15:56 | bauzas | voilà | |
| 16:15:59 | bauzas | moving on | |
| 16:16:03 | bauzas | #topic Review priorities | |
| 16:16:15 | bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement)+label:Review-Priority%252B1 | |
| 16:16:16 | dansmith | also leading space | |
| 16:16:45 | bauzas | dansmith: good catch, the copy/paste makes me mad | |
| 16:16:50 | bauzas | #topic Review priorities | |
| 16:16:57 | bauzas | #undo | |
| 16:16:57 | opendevmeet | Removing item from minutes: #topic Review priorities | |
| 16:17:25 | bauzas | fun, the meetbot isn't telling new topics | |
| 16:17:33 | bauzas | anyway, next point | |
| 16:17:35 | dansmith | it doesn't on oftc I think | |
| 16:17:42 | bauzas | #action bauzas to propose a documentation change by this week as agreed on the PTG | |
| 16:17:47 | dansmith | but if you don't do it #properly it won't record them either | |
| 16:18:13 | bauzas | for adding a gerrit ACL to let contributors +1ing | |
| 16:18:31 | bauzas | didn't had time to formalize it yet | |
| 16:18:49 | bauzas | #topic Stable Branches | |
| 16:18:59 | bauzas | elodilles: floor is yours | |
| 16:20:02 | bauzas | I guess he's not around | |
| 16:20:05 | bauzas | so I'll paste | |
| 16:20:14 | bauzas | stein and older stable branches are blocked, needs the setuptools pinning patch to unblock: https://review.opendev.org/q/I26b2a14e0b91c0ab77299c3e4fbed5f7916fe8cf | |
| 16:20:37 | bauzas | we need a second stable core especially on https://review.opendev.org/c/openstack/nova/+/813451 | |
| 16:21:00 | bauzas | Ussuri Extended Maintenance transition is scheduled to next week (Nov 12) | |
| 16:21:07 | bauzas | the list of open and unreleased patches: https://etherpad.opendev.org/p/nova-stable-ussuri-em | |
| 16:22:18 | bauzas | I guess we need to make a few efforts before ussuri becomes EM | |
| 16:22:31 | bauzas | elodilles: again, I offer my help if you ping me | |
| 16:22:44 | bauzas | patches that need one +2 on ussuri: https://review.opendev.org/q/project:openstack/nova+branch:stable/ussuri+is:open+label:Code-Review%253E%253D%252B2 | |
| 16:23:08 | bauzas | (I'll skim this list) | |
| 16:23:22 | elodilles | oh, sorry, DST :S | |
| 16:23:24 | bauzas | last but not least: https://review.opendev.org/806629 patch (stable/train) needed 14 rechecks, I was pinged with the question whether testing should be reduced in train to avoid this amount of rechecks (mostly volume detach issue) | |
| 16:23:54 | bauzas | elodilles: hah, I warned about it in the channel :p | |
| 16:24:06 | sean-k-mooney[m] | are the detach issue due to the qemu version we have in bionic | |
| 16:24:28 | sean-k-mooney[m] | i assume train is not on focal? | |
| 16:24:36 | elodilles | yes, train is on bionic | |
| 16:24:50 | elodilles | (just like ussuri) | |
| 16:26:34 | bauzas | hmmm, technically, Train is EM | |
| 16:26:53 | sean-k-mooney[m] | im somewhat tempeted to same maybe move it to centos 8 or focal but we could disable the volume tests | |
| 16:26:59 | sean-k-mooney[m] | yes it is | |
| 16:27:11 | bauzas | I'd rather prefer us fixing the gate issues rather than reducing the test coverage, but this depends on any actions we can take | |
| 16:27:24 | bauzas | so, let's be pragmatic | |
| 16:28:17 | sean-k-mooney[m] | well the first question would be does train have gibis event based witing patch or is it still using the retry loop | |
| 16:28:39 | bauzas | gibi's patch isn't merged yet, right? | |
| 16:28:44 | bauzas | could it help ? | |
| 16:28:57 | sean-k-mooney[m] | the only options reallly to fi this are change the qemu verions or backport gibis patch | |
| 16:29:10 | bauzas | (I'll have to leave gibi chair in the next 2 mins but dansmith has a point I'm interested in) | |
| 16:29:37 | dansmith | I also have to go sooner | |
| 16:29:43 | bauzas | sean-k-mooney[m]: we can try to backport gibi's patch and see whether that helps | |
| 16:29:45 | dansmith | maybe we could swap open and libvirt? | |
| 16:29:52 | bauzas | dansmith: I'll | |
| 16:29:59 | gibi | I don't think there is anything in the libvirt topic | |
| 16:30:02 | gibi | lyarwood is out now | |
| 16:30:09 | dansmith | okay | |
| 16:30:21 | bauzas | okay, elodilles I'll propose to wait for gibi's patch to land in master and then be backported | |
| 16:30:32 | gibi | bauzas: it is backported til wallaby | |
| 16:30:33 | elodilles | bauzas: ack | |
| 16:30:34 | bauzas | and punt the decision to reduce the test coverage once we get better ideas | |
| 16:30:41 | gibi | if we are talking about https://review.opendev.org/q/topic:bug/1882521 | |
| 16:31:09 | bauzas | gibi: then we need to backport it down to train | |
| 16:31:13 | gibi | I don't think it will be a piece of cake to bring that back train | |
| 16:31:20 | gibi | *to train | |
| 16:31:32 | bauzas | gibi: (apologies I confused with the vnic types waiting patch) | |
| 16:31:59 | bauzas | I have to leave, but can we hold this one discussion and go straight to dansmith's point | |
| 16:32:01 | bauzas | ? | |
| 16:32:09 | gibi | anyhow we can take that outside when lyarwood is back | |
| 16:32:09 | bauzas | so I and dansmith can leave | |
| 16:32:21 | gibi | lets go to that | |
| 16:32:25 | bauzas | #topic Sub/related team Highlights | |
| 16:32:27 | bauzas | nothing to tell | |
| 16:32:32 | bauzas | #topic Open discussion | |
| 16:32:37 | bauzas | Bring default overcommit ratios into sanity (dansmith / yuriys) | |
| 16:32:39 | dansmith | So, I think we all know the default 16x cpu overcommit default is insane | |
| 16:32:41 | yuriys | exciting | |
| 16:32:54 | dansmith | we've got reports that some operators are USING those defaults because they think we're recommending them | |
| 16:32:59 | sean-k-mooney[m] | yes it is | |
| 16:33:04 | yuriys | I am so used to Slack and Discord for drop a paragraph level of communication, so pardon all the incoming spam! I prewrote stuff. | |
| 16:33:04 | bauzas | hah | |
| 16:33:08 | dansmith | yuriys is here to offer guidance and help work on this, | |
| 16:33:21 | dansmith | but I think we need to move those defaults to something sane, both in code and update the docs | |
| 16:33:28 | bauzas | I guess this can be workload dependent, right? | |
| 16:33:29 | sean-k-mooney[m] | it basically should not be set over 4x | |
| 16:33:39 | yuriys | 4:1 for cpu , 1:1 for mem. | |
| 16:33:44 | sean-k-mooney[m] | yep | |
| 16:33:48 | bauzas | I think we started to document things based on workloads | |
| 16:33:56 | yuriys | yes | |
| 16:33:58 | dansmith | bauzas: it's completely workload dependent, but we should not be recommending really anything, and thus I think the default needs to be closer to 1:1 with docs saying why you may increase it (or not) | |
| 16:33:58 | bauzas | but we never achieved this | |
| 16:34:01 | yuriys | it's VERY use case specific | |