| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-15 | |||
| 14:44:37 | jaypipes | merci | |
| 14:44:59 | bauzas | mmm, he's not on our internal IRC, lemme verify if he has some PTO | |
| 14:48:50 | jaypipes | bauzas: ok, no worries. | |
| 14:49:08 | bauzas | jaypipes: well, I don't see any PTO on our agenda | |
| 14:49:24 | jaypipes | bauzas: danpb isn't available is he? | |
| 14:50:03 | jaypipes | bauzas: specifically, I am looking to find out whether Dan's comment here: https://review.openstack.org/#/c/527631/9/nova/virt/libvirt/driver.py@a4299 (that was removed by tetsuro) is still valid. | |
| 14:50:18 | bauzas | jaypipes: I can ask danpb to go here | |
| 14:50:25 | jaypipes | bauzas: cool, cheers :) | |
| 14:50:34 | bauzas | even if he's no longer working on nova | |
| 14:52:36 | stephenfin | jaypipes: kashyap is the person to ask about that | |
| 14:52:47 | stephenfin | Far as I know, that comment is still valid. We've got support or emulator threads enabled but not IO threads | |
| 14:53:02 | kashyap | And clicks on the URL | |
| 14:53:03 | stephenfin | However, iirc, kashyap was in talks where the value of IO threads was called into question | |
| 14:53:22 | stephenfin | Well, IO threads > 1 anyway | |
| 14:53:35 | kashyap | stephenfin: jaypipes: (I have a discussion for it (IO Threads at Dublin too) | |
| 14:53:38 | kashyap | That said... | |
| 14:55:06 | kashyap | Yeah, the IO Threads value is in contention | |
| 14:55:33 | kashyap | Recently, I saw a presentation at KVM Forum where someone from oVirt claimed the "ideal" number of IO Threads is ...1! | |
| 14:55:37 | kashyap | (In their benchmarks) | |
| 14:56:01 | kashyap | But I won't believe it. "Seeing is believing" --> Need `fio` benchmarks for that | |
| 14:57:59 | kashyap | jaypipes: Also see: https://review.openstack.org/#/c/230968/ "iothreads for disk devices" | |
| 14:59:17 | jaypipes | kashyap: so, bottom line, that comment from danpb is still valid, yeah? | |
| 14:59:19 | bauzas | jaypipes: when you have time, I'd also like to discuss abotu https://review.openstack.org/#/c/544683/1 | |
| 14:59:32 | kashyap | jaypipes: Yes, it is still valid; it's better to retain that | |
| 14:59:42 | kashyap | (I.e. I agree with your comment on Gerrit) | |
| 15:00:04 | kashyap | Nova isn't yet using IO Threads. | |
| 15:00:51 | jaypipes | danke | |
| 15:01:13 | jaypipes | kashyap: dan just responded. | |
| 15:02:07 | kashyap | jaypipes: I think you're trying to speak Dutch, in that case: "Dank je" / "Heel erg bedant" :P | |
| 15:02:13 | kashyap | (You wrote German) | |
| 15:02:27 | kashyap | If that was intentional; disreregard me | |
| 15:03:21 | openstackgerrit | Dan Smith proposed openstack/nova-specs master: Support member_of param for allocation candidates https://review.openstack.org/544694 | |
| 15:04:11 | jaypipes | kashyap: oh, I wasn't trying to write Dutch... I just say danke all the time... | |
| 15:04:23 | jaypipes | dansmith: why thank you dan | |
| 15:04:26 | kashyap | True; I've noticed it before | |
| 15:04:31 | dansmith | cha | |
| 15:05:20 | mriedem | melwitt: mnaser: i've gone through the local delete https://review.openstack.org/#/c/340614/ change in detail, lots of questions and head scratching | |
| 15:05:33 | jaypipes | stephenfin: I -W'd https://review.openstack.org/#/c/527630/ since the blueprint isn't yet approved.. | |
| 15:06:13 | stephenfin | Oh, good catch. It is just cleanup though, right? | |
| 15:06:25 | mriedem | 527630 is in the gate | |
| 15:06:29 | efried | cdent, jaypipes: Can we talk about the "2001 providers" issue from https://review.openstack.org/#/c/540111/ ? | |
| 15:06:30 | mriedem | you're going to have to rebase it to pull it out | |
| 15:06:32 | mriedem | or change the commit message | |
| 15:06:37 | mriedem | jaypipes: stephenfin: ^ | |
| 15:06:37 | stephenfin | Do we want to? | |
| 15:07:15 | cdent | efried: I can if you like but it will be partial attention, doing tc office hours then api-s | |
| 15:07:16 | cdent | ig | |
| 15:07:21 | openstackgerrit | Dan Smith proposed openstack/nova master: Add request filter functionality to scheduler https://review.openstack.org/544730 | |
| 15:07:22 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Add require_tenant_aggregate request filter https://review.openstack.org/545002 | |
| 15:07:28 | stephenfin | jaypipes: I'll let you call that | |
| 15:07:57 | jaypipes | mriedem: it's just a small refactor. if you want to keep it in, that's OK with me. but the series is associated with a blueprint that is not approved, as you know. | |
| 15:08:18 | jaypipes | efried: sure. hangout or IRC? | |
| 15:08:33 | mriedem | i haven't been tracking it, just saw you mention that | |
| 15:08:36 | efried | cdent, jaypipes, edleafe: If y'all are okay with limiting based on the MISC_SHARES_VIA_AGGREGATE trait, at least for now, I'll make it so. If I'm the only one who's uncomfortable about that, and I can't give a good reason/counterexample, then I'm okay to let it ride. | |
| 15:08:50 | jaypipes | mriedem: for some reason I thought -W would prevent it from gating... | |
| 15:08:56 | dansmith | jaypipes: nay | |
| 15:08:57 | efried | jaypipes, mriedem: A -2 might | |
| 15:09:02 | jaypipes | ah | |
| 15:09:09 | jaypipes | well I don't want to do that... | |
| 15:09:09 | mriedem | no, the best thing with stuff that's not bp approved right now, is don't +2 it | |
| 15:09:11 | dansmith | a -2 will, but it will reset the gate at the last moment | |
| 15:09:22 | bauzas | dansmith: oh, saw https://review.openstack.org/#/c/544585/ | |
| 15:09:28 | mriedem | +1 if you wanted to review it and said lgtm but the bp isn't approved yet | |
| 15:10:26 | dansmith | bauzas: came out of discussing some concerns with CERN | |
| 15:10:41 | bauzas | okay, I need to review it carefully then | |
| 15:10:57 | bauzas | I wasn't really paying attention to specs yet | |
| 15:11:39 | jaypipes | stephenfin: I -W'd the following patch. | |
| 15:11:45 | dansmith | bauzas: it's pretty simple, and you can see my prototype code which is probably easier to grok | |
| 15:11:47 | jaypipes | stephenfin: and left the one small refactoring in the gate. | |
| 15:11:56 | bauzas | dansmith: yeah, will look | |
| 15:12:04 | stephenfin | jaypipes: Cool. I had concerns about that one anyway (though it's also a refactoring change) | |
| 15:12:36 | jaypipes | efried: let me comment on the spec. | |
| 15:12:56 | efried | jaypipes: ack, thx. I'd like to answer the question in the text before it's published. | |
| 15:13:14 | jaypipes | ya | |
| 15:13:18 | efried | edleafe: btw, we're talking about https://review.openstack.org/#/c/540111/4/specs/rocky/approved/update-provider-tree.rst@48 | |
| 15:16:40 | dansmith | mriedem: you're going to let me know when I can un -W this right? https://review.openstack.org/#/c/543580/ | |
| 15:18:17 | mriedem | preferably after rc2 | |
| 15:18:55 | jaypipes | efried: done | |
| 15:29:02 | edleafe | efried: was getting coffee. Makes sense to limit the tree by that trait. | |
| 15:29:10 | mriedem | melwitt: i thought about this earlier today for some reason: if anyone, new contributor, stephen, whoever :) wants to start converting mox to mock in nova, they should definitely either way for cellsv1 and nova-net removal first, or be sure to stear clear from converting any tests that touch those code paths | |
| 15:29:24 | mriedem | *wait | |
| 15:29:44 | efried | edleafe: Rgr, thx | |
| 15:34:43 | bauzas | dansmith: question for you, why can't we leave Placement return all the hosts and only select the ones from that or this in a filter ? | |
| 15:35:07 | bauzas | dansmith: you described that in https://review.openstack.org/#/c/544585/6/specs/rocky/approved/placement-req-filter.rst@115 IIRC but it's a bit confusing for me | |
| 15:35:39 | dansmith | bauzas: because cern would have to process 9000 hosts that couldn't possibly work before they get to the first one that would | |
| 15:36:14 | dansmith | bauzas: if you have a 10k node deployment with lots of space, and you boot a small instance, you get back a ridiculous number of hosts that you're not allowed to use and we have to run filters on all of them | |
| 15:36:23 | bauzas | dansmith: it ties to a Placement performance question, right? | |
| 15:36:28 | dansmith | no | |
| 15:36:36 | dansmith | placement is fast at doing that, | |
| 15:36:47 | dansmith | scheduler is slow at processing the result | |
| 15:36:48 | bauzas | dansmith: because for that kind of purpose, we always say to use the more important filters first | |
| 15:36:53 | mriedem | melwitt: i've started a technical debt / cleanup section in https://etherpad.openstack.org/p/nova-ptg-rocky L157 | |
| 15:37:09 | dansmith | bauzas: at CERN-level scale, that is still very wasteful | |
| 15:37:10 | bauzas | dansmith: since each filter is processed one after the other, depending on the ordering of the list | |
| 15:37:36 | bauzas | dansmith: did they found some bottleneck ? | |
| 15:37:49 | dansmith | bauzas: did you read the irc conversation? | |
| 15:37:55 | bauzas | because the last benches I had from the scheduler, the filtering process itself was way fast | |
| 15:38:18 | bauzas | dansmith: from the cells meeting ? unfortunately no | |
| 15:38:25 | dansmith | bauzas: we also only request 1000 hosts from placement, so if your hosts are after the first thousand, we wouldn't get back any that work for us | |
| 15:38:31 | dansmith | bauzas: no, linked in the spec | |