| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-15 | |||
| 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 | |
| 15:38:47 | mriedem | bauzas: cern ties tenants to cells, | |
| 15:38:56 | mriedem | so top level cells v1 scheduler will pick the cell for the tenant, | |
| 15:39:01 | mriedem | but with cells v2, we have a flat scheduler, | |
| 15:39:12 | dansmith | bauzas: so if you have more than 1000 hosts that could fit your size flavor, but the first one you're allowed to use is after that, you could never schedule, or have to bump that limit higher | |
| 15:39:20 | mriedem | so rather than a request from that tenant being just the computes in the chosen child cell, now it's all hosts from all cells, | |
| 15:39:21 | mriedem | as dan pointed out | |
| 15:39:48 | dansmith | and, any hard requirement we (nova) knows about that it can communicate to placement ahead of time will only improve performance, and ensure we get back a richer set of hosts to choose from | |
| 15:40:03 | dansmith | and "can never be on hosts in aggregate X" is a pretty concrete requirement :) | |
| 15:40:08 | bauzas | dansmith: mriedem: I understand that concern | |
| 15:40:20 | bauzas | I just wonder how big it can become | |
| 15:40:25 | mriedem | i like to also think of this as a way to eventually get rid of these other post-placement filters | |
| 15:40:34 | dansmith | yeah | |