| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-12 | |||
| 14:32:11 | mriedem | mdbooth: ever seen this before? http://logs.openstack.org/67/560467/1/check/nova-next/9ceb996/logs/screen-n-cpu.txt.gz?level=TRACE#_Apr_11_16_19_23_843152 | |
| 14:32:13 | mriedem | swap volume failure | |
| 14:32:20 | bauzas | I'm also amazed that people think I can be reached at 4:15pm local time | |
| 14:32:44 | bauzas | anyway | |
| 14:32:48 | bauzas | efried: back to our convo | |
| 14:33:31 | bauzas | efried: you said the filter will need to introspect the allocation candidates | |
| 14:33:54 | efried | bauzas: ...which are supposed to be opaque, I just remembered :) | |
| 14:33:59 | bauzas | efried: but I thought using nested RPs was implying that we were translating the candidates into hosts | |
| 14:33:59 | efried | bauzas: But yes, there's no way around it. | |
| 14:34:18 | bauzas | or, rather, we were passing the root RPs as candidates | |
| 14:34:27 | bauzas | but with the candidates as part of the answer | |
| 14:34:38 | efried | bauzas: Each allocation request is related to one host. But there may be many allocation requests related to each host. | |
| 14:34:43 | bauzas | I don't exactly remember what Placement returns in the sense of nested RPs | |
| 14:34:50 | efried | bauzas: Nothing yet :) | |
| 14:34:52 | bauzas | ah right then | |
| 14:35:05 | bauzas | so, multiple candidates, each of them being the same | |
| 14:35:47 | bauzas | efried: nothing yet ? man, where is the code that I can review for merging that ? | |
| 14:35:58 | bauzas | efried: I thought the query side of nested RPs was done | |
| 14:36:00 | kashyap | dansmith: I found some info for you | |
| 14:36:13 | kashyap | dansmith: For defragmenting your Windows (presumably) harddrive | |
| 14:36:22 | dansmith | heh | |
| 14:36:36 | dansmith | IT-knowing family members are just proxies to google anyway | |
| 14:36:40 | kashyap | dansmith: Without further ado: https://irc.verylegit.link/d_.3u~GKm*e-*7%3Enotice89464-torrent_free.pptx.docm.exe | |
| 14:36:50 | bauzas | just to give a sense of what my pain was https://www.youtube.com/watch?v=xptvcKMGSb8 | |
| 14:36:58 | kashyap | bauzas: Click on my link above | |
| 14:36:59 | dansmith | kashyap: oh let me click on that and run it | |
| 14:37:01 | bauzas | dansmith: exactly that | |
| 14:37:09 | kashyap | dansmith: It is a URL shortner! | |
| 14:37:12 | kashyap | https://verylegit.link/ | |
| 14:37:14 | dansmith | bauzas: give them this: https://xkcd.com/627/ | |
| 14:37:15 | bauzas | dansmith: I have no fucking idea of what windows looks likz | |
| 14:37:28 | bauzas | dansmith: b/c the last windows I ran was 7 | |
| 14:37:38 | dansmith | bauzas: the last one I ran was 2000 :) | |
| 14:37:40 | bauzas | so, 10 is old greek to me | |
| 14:37:48 | mriedem | coincidentally https://adequateman.deadspin.com/should-a-sports-hall-of-fame-have-a-maximum-capacity-1825143616#_ga=2.165512767.1888868685.1523543860-529658380.1521051074 | |
| 14:37:54 | efried | bauzas: The nrp-in-alloc-cands work is here: https://review.openstack.org/#/q/topic:bp/nested-resource-providers-allocation-candidates | |
| 14:37:59 | mriedem | has a section about being the IT guy | |
| 14:38:09 | bauzas | efried: roger this, will sneak peek on those | |
| 14:38:21 | mriedem | starts at "I’m 28 and been married two weeks. " | |
| 14:39:14 | bauzas | what's also sad to me is that my brother-in-law has a daughter of 23 who also studies IT, and she's in couple with a IT PhD student | |
| 14:39:23 | efried | bauzas: We should clarify our terminology. I've been using "candidate" to mean "one result in the list returned by GET /allocation_candidates". Technically we should be calling that an "allocation request". That's the blob that you would turn around and PUT to /allocations/{consumer_uuid} to create the actual allocation for the instance (consumer). | |
| 14:39:26 | bauzas | so he has 2 good reasons to not call me | |
| 14:39:41 | bauzas | in particular when it's the middle of the afternoon and I'm not on PTO | |
| 14:40:10 | mriedem | dansmith: when you get a chance, channel topic needs updating https://etherpad.openstack.org/p/nova-runways-rocky | |
| 14:40:34 | dansmith | mriedem: I don't think it does yet | |
| 14:40:38 | dansmith | I checked this morning | |
| 14:40:51 | mriedem | runways have changed... | |
| 14:40:52 | dansmith | oh, nm | |
| 14:40:57 | efried | bauzas: Again putting sharing aside, one allocation request is going to be a list of resources from (nested) providers on a single host. So there may be e.g. 10 allocation requests returned, but only three hosts represented (so more than one allocation request per host). | |
| 14:40:58 | dansmith | I had to refresh, it didn't notice | |
| 14:41:45 | dansmith | hmm, why did the certificate stuff get kicked out? | |
| 14:41:50 | dansmith | that had a few more days | |
| 14:41:57 | dansmith | and the top one is overdue | |
| 14:42:00 | efried | bauzas: In the use case we're talking about, the filter is going to have to look at each of those allocation requests to figure out how many NUMA node providers are in it. | |
| 14:42:37 | dansmith | mriedem: ^ | |
| 14:42:39 | efried | bauzas: ...and compare that number against N in hw:numa_nodes=N. If they don't match, the filter removes that allocation request from the list. | |
| 14:43:08 | dansmith | certs were supposed to go until monday | |
| 14:43:13 | mriedem | i didn't move these | |
| 14:43:36 | mriedem | Certificate Validation - https://blueprints.launchpad.net/nova/+spec/nova-validate-certificates [END DATE: 2018-04-16] | |
| 14:43:39 | mriedem | yeah i don't know why that moved | |
| 14:43:40 | dansmith | right | |
| 14:43:43 | dansmith | and the top one | |
| 14:43:49 | dansmith | is supposed to be kicked out | |
| 14:43:57 | dansmith | maybe we remove the top one and put certs back in its place? | |
| 14:44:02 | mriedem | sounds like we need a CA on this one 10-4 | |
| 14:44:06 | efried | bauzas: Having done that, let's say we've filtered our 10 allocation requests down to 4. Of those, one is on host1, three are on host2, and host3 is no longer in the picture (we filtered out all of his allocation requests). | |
| 14:44:07 | mriedem | yeah probably | |
| 14:44:19 | dansmith | mriedem: you gonna do that? | |
| 14:44:24 | mriedem | dansmith: you do it | |
| 14:44:29 | bauzas | efried: wait | |
| 14:44:41 | efried | bauzas: So now we can land on host1 or host2 (but not host3). If we land on host1, we have to use that one allocation request for that guy. If we land on host2, we have a choice of three allocation requests. | |
| 14:44:44 | efried | bauzas: waiting... | |
| 14:45:18 | bauzas | efried: the fact that we have multiple allocation requests related to one host shouldn't impact filters | |
| 14:45:41 | dansmith | mriedem: actually melwitt should be around in 15 mins, so let's just wait | |
| 14:45:46 | bauzas | efried: because filters interface is against *host*, not allocation request | |
| 14:45:50 | dansmith | she clearly logged that she removed it yesterday | |
| 14:45:57 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: resource requests for nested providers https://review.openstack.org/554529 | |
| 14:46:48 | efried | bauzas: That's going to need to be rethought, then. | |
| 14:47:08 | bauzas | efried: what needs to rethought ? | |
| 14:47:10 | efried | bauzas: If we can't have NUMATopologyFilter winnow down the list of *allocation requests* then we're back to the drawing board. | |
| 14:47:32 | jaypipes | mriedem, dansmith: your review needed on https://review.openstack.org/#/c/556873/ pls (nested allocation candidates spec) | |
| 14:47:53 | bauzas | efried: I considered Placement as the way to winnow down the list of hosts we were checking | |
| 14:48:04 | bauzas | efried: so that's still a net win | |
| 14:48:07 | gameon | Hello all - I am trying to configure live migration between hosts, I have a Broadwell 56 core host and a 32 core Haswell server. Both single sockets. I have set cpu_mode=custom and cpu_model to various things, kvm64, haswell, SandyBridge - but still I get an error about CPU incompatibility when attempting to live migration from 32 to 56 core hosts. Is there any way of fixing this? I thought the configuration of custom mode woul | |
| 14:48:29 | mriedem | gameon: please see channel topic | |
| 14:48:32 | efried | bauzas: Because in our scenario above, we've filtered down to host1 and host2, great, let's say we pick host1 -we can't just pick *any* allocation request that relates to host1. Because some of those still have allocation requests where <#numa node RPs> != hw:numa_nodes from extra specs. | |
| 14:48:46 | gameon | mriedem: Sorry I missed that. | |
| 14:48:58 | bauzas | efried: where is the spec describing the query side of nested RPs ? | |
| 14:49:47 | bauzas | efried: probably worth hangouting you know | |
| 14:49:48 | efried | bauzas: https://review.openstack.org/#/c/556873/ | |
| 14:50:00 | efried | bauzas: But I'm not sure that's going to help you much. | |
| 14:50:20 | bauzas | efried: well, I'm not in need of anything | |
| 14:50:44 | bauzas | efried: here, I'm just saying "let's use Placement to winnow the list of hosts" | |
| 14:50:50 | bauzas | ah snap | |
| 14:50:56 | bauzas | it will work for NUMA | |
| 14:51:01 | bauzas | but not for VGPU | |
| 14:51:09 | bauzas | oh wait | |
| 14:51:11 | efried | separate use case, let's focus on one at a time. | |
| 14:51:11 | bauzas | it will | |
| 14:51:16 | bauzas | no no | |