| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-12 | |||
| 14:03:49 | efried | jaypipes: We're talking about how nova is going to use placement | |
| 14:04:00 | stephenfin | efried: Oh, because the same host can be presented multiple ways? | |
| 14:04:08 | bauzas | jaypipes: the problem is that I'd love to see some NUMA experts chiming in | |
| 14:04:11 | efried | stephenfin: yes, exactly. | |
| 14:04:18 | stephenfin | efried: gotcha. Cheers | |
| 14:04:28 | bauzas | efried: again, I don't think there is a problem | |
| 14:04:41 | stephenfin | jaypipes: The damage should be limited to the west (?) coast. I'll be fine ;) | |
| 14:04:57 | bauzas | efried: the fact that placement is returning a list of candidates won't trample what the filter already does | |
| 14:05:15 | bauzas | if the filter restricts, cool | |
| 14:05:55 | bauzas | and again, if we want to make Placement restricting, let's do that *in a separate spec* | |
| 14:06:21 | efried | bauzas: don't think of numa nodes as candidates. Ignoring sharing for now, one allocation candidate (technically allocation request) will include resources from one host. The resources for each allocation request will be spread across one or more providers (numa nodes) in the tree. The filter will have to inspect each allocation request to see if the number of NUMA nodes represented equals the number of hw:numa_nodes in | |
| 14:06:23 | jaypipes | stephenfin: :) | |
| 14:06:57 | efried | bauzas: And remove the *allocation requests* where that's not the case. | |
| 14:07:36 | efried | bauzas: Now you'll still have X allocation requests representing results for Y hosts, where Y<=X | |
| 14:07:52 | bauzas | sec, otp | |
| 14:08:40 | efried | stephenfin or bauzas: wanna unblock the gate? https://review.openstack.org/#/c/560909/ | |
| 14:08:49 | stephenfin | efried: sure | |
| 14:09:12 | stephenfin | done | |
| 14:12:23 | mriedem | i see the problem | |
| 14:12:25 | mriedem | but don't understand it | |
| 14:12:30 | mriedem | https://review.openstack.org/#/c/554317/3/playbooks/legacy/nova-multiattach/run.yaml | |
| 14:12:36 | mriedem | removed ENABLE_UBUNTU_CLOUD_ARCHIVE=False right? | |
| 14:12:39 | mriedem | http://logs.openstack.org/17/554317/3/check/nova-multiattach/fd35a93/logs/local.conf.txt.gz | |
| 14:12:43 | mriedem | ENABLE_UBUNTU_CLOUD_ARCHIVE=False is in there | |
| 14:13:56 | mriedem | that's why it's blowing up | |
| 14:14:39 | mriedem | http://logs.openstack.org/17/554317/3/check/nova-multiattach/fd35a93/ara-report/result/ab8397a6-593e-43f5-a593-c2633a0e40de/ | |
| 14:14:53 | mriedem | idk what's up there but it looks like zuul isn't taking that change | |
| 14:15:00 | mriedem | mordred: you around for a zuul question? | |
| 14:16:38 | mriedem | there was a zuulv3 code deploy last night... | |
| 14:23:22 | mriedem | https://storyboard.openstack.org/#!/story/2001839 for anyone that cares | |
| 14:23:34 | mriedem | the job on master is picking up changes from the playbook in stable/queens | |
| 14:27:24 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use Queens UCA for nova-multiattach job https://review.openstack.org/554317 | |
| 14:29:03 | bauzas | efried: back | |
| 14:29:20 | bauzas | IT person curse | |
| 14:29:41 | bauzas | my brother-in-law called me (while I'm at work!) for some personal issue with windows 10 | |
| 14:29:52 | bauzas | not kidding | |
| 14:30:06 | bauzas | one day, I'll explain to my family that : | |
| 14:30:16 | bauzas | #1 I have a real job even if working at home | |
| 14:30:26 | openstackgerrit | Jay Pipes proposed openstack/nova master: mirror nova host aggregate members to placement https://review.openstack.org/553597 | |
| 14:30:36 | bauzas | #2 working on IT doesn't mean I'm expert in windows-ishings | |
| 14:30:53 | dansmith | bauzas: can you help me defrag my hard drive? | |
| 14:31:03 | dansmith | bauzas: also, I think I have a virus | |
| 14:31:22 | dansmith | bauzas: what's your preferred program for video editing on my windows pc? | |
| 14:31:23 | bauzas | dansmith: my brother-in-law has no fucking idea of what 'defrag' means :p | |
| 14:31:46 | dansmith | bauzas: can you recommend a printer for laying ink on dead tree carcass since that's a thing I do | |
| 14:31:47 | dansmith | bauzas: hah | |
| 14:32:06 | dansmith | bauzas: relaying recent questions I have gotten since you're apparently the windows IT expert | |
| 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 | |