| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-11 | |||
| 15:27:04 | bauzas | like VCPU and MEMORY_MB | |
| 15:27:07 | efried | Because VGPU and VCPU are in different resource providers. | |
| 15:27:20 | efried | bauzas: So you can't put them in the same numbered request group. | |
| 15:27:27 | bauzas | efried: that will depend on the operator | |
| 15:27:30 | kashyap | mriedem: Also, I can understand if you are of the view of: "I won't touch them until Zuul is +1 on them, and you've dropped all no-more-relevant compat code" :-) | |
| 15:27:35 | efried | bauzas: And if you put them in different request groups, they aren't guaranteed to land on the same NUMA node. | |
| 15:27:39 | bhagyashris | efried: it's working now :) | |
| 15:28:03 | efried | bhagyashris: Like, fully working? Like the DISK_GB is being reported by the sharing provider and not by the compute node provider? | |
| 15:28:08 | bauzas | efried: but if they want NUMA affinity for VGPUs, then the doc will say : enable the conf opt saying "I want VCPU and VGPU to be NUMA specific" | |
| 15:28:17 | bauzas | efried: in that case, they will be on the same RP | |
| 15:28:25 | bauzas | efried: which will make the thing work | |
| 15:28:39 | mriedem | kashyap: i'd prefer to not dig into those until tests are passing | |
| 15:29:05 | efried | bauzas: It would. But saying that the VGPU inventory has to be on the same RP as the VCPU inventory - that's not a restriction that's going to remain viable for very long. | |
| 15:29:05 | bauzas | efried: we could later add a new param that specifically request the notion of the "subtree" parenting, but I leave that out of that spec then | |
| 15:29:25 | kashyap | mriedem: Sure, that's perfectly fine. I will be able to full spend time on it only from Friday afternoon onwards. | |
| 15:29:39 | bauzas | efried: sure, but I don't want to boil the ocean and keep the NUMA spec minimalist | |
| 15:29:42 | bhagyashris | efried: yes it removes the CN RP DISK_GB inventory from inventory table and now it's reporting the resource against the CN and shared RP :) | |
| 15:29:48 | efried | bhagyashris: WOHOO! jaypipes ^^ | |
| 15:30:11 | bauzas | efried: I can leave a note explaining the caveat, and someone in the future (possibly being me) could write another spec describing the problem and the solution | |
| 15:30:14 | efried | bauzas: Okay, then the spec needs to state that restriction, for sure, cause that's significant. | |
| 15:30:41 | bauzas | efried: that's correct, I'll amend the spec accordingly and explicitely state the limitation, exactly like I did for huge pages | |
| 15:30:51 | bauzas | efried: thanks for your help! | |
| 15:31:02 | bhagyashris | efried: thanks for your inputs :) Now it's EOD for me leaving... | |
| 15:31:29 | efried | bauzas: TBC: the restriction means that the ascii diagram you've shown on L125 (where the VGPU and VF inventories are separated from the VCPU/PCUP/MEMORY_MB) will *not* work. | |
| 15:31:44 | bauzas | that's right, I need to amend the diagram too | |
| 15:31:50 | efried | bauzas: Cool cool. | |
| 15:31:57 | efried | bhagyashris: Thank you very much for working this. | |
| 15:32:55 | efried | jaypipes: To summarize, bhagyashris validated that these two patches DTRT wrt sharing DISK_GB for libvirt: https://review.openstack.org/560444 https://review.openstack.org/560459 | |
| 15:33:19 | jaypipes | efried: DTRT? | |
| 15:33:22 | jaypipes | do the right thign? | |
| 15:33:29 | efried | yes | |
| 15:33:33 | jaypipes | you kids... | |
| 15:33:56 | jaypipes | efried, bhagyashris: ok, cool. that's kind of exactly what I expected. :) | |
| 15:35:53 | efried | jaypipes: Now somebody ought to finish up the tests on those patches and put 'em to bed. | |
| 15:42:43 | jaypipes | bauzas: you realize that https://devblogs.nvidia.com/performance-portability-gpus-cpus-openacc/ is not talking about CPU and GPU sharing memory, right? | |
| 15:42:56 | bauzas | right | |
| 15:43:04 | bauzas | it's about portability | |
| 15:43:28 | bauzas | memory isn't shared on a SOC for a nvidia card | |
| 15:43:44 | bauzas | so you're right, that's a separate memory map | |
| 15:44:57 | jaypipes | bauzas: you wrote "I have many internal customers that are actually very interested in having NUMA affinity for having the GPU memory close as possible to the NUMA memory controller used by the virtual CPU" <-- that is just not the case. | |
| 15:45:17 | jaypipes | bauzas: either that, or your internal customers don't actually know what they're asking for. | |
| 15:45:45 | bauzas | jaypipes: I can certainly ask them for clarification about their needs | |
| 15:46:15 | jaypipes | bauzas: in any case, that wasn't the reason for the -1 :) was just mentioning the use case could have been tighter. | |
| 15:46:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove RequestContext.instance_lock_checked https://review.openstack.org/554378 | |
| 15:47:32 | bauzas | jaypipes: yeah, no worries, I got it | |
| 15:47:43 | bauzas | jaypipes: and tbh, I appreciate you challenging me on the need | |
| 15:47:57 | bauzas | because it helps me understand why my customers are pushing for it | |
| 15:48:18 | bauzas | instead of just be a typey typey box | |
| 15:49:34 | jaypipes | bauzas: yeah, the checkboxy thing is a big problem. | |
| 15:55:11 | mriedem | mikal: i'm sure this pains you, but apparently the nova-net refactoring broke nova-lxd https://review.openstack.org/#/c/559190/ which apparently also broke openstack-ansible https://review.openstack.org/#/c/559354/ | |
| 15:55:13 | mriedem | :( | |
| 15:57:11 | jaypipes | tssurya: you need any assistance on writing the func test asked for by dansmith on https://review.openstack.org/#/c/554920/? | |
| 15:57:39 | melwitt | dansmith: for the runways end dates, were you thinking they include the end date? that is, would we remove things *on* the end date or the day after? I was thinking the day after | |
| 15:57:54 | tssurya | jaypipes: I have been working on it for sometime with not much luck | |
| 15:58:04 | dansmith | melwitt: shrug, probably EOD on the day yeah | |
| 15:58:05 | dansmith | which is today I know | |
| 15:58:10 | jaypipes | tssurya: feel free to push what you've got and I can help out. | |
| 15:58:14 | tssurya | jaypipes : so if you have some time, help appreciated | |
| 15:58:18 | jaypipes | np | |
| 15:58:37 | melwitt | dansmith: yeah, okay. I was thinking similar, that the end date should include that day. I'll move things after EOD | |
| 15:58:55 | dansmith | melwitt: your EOD is pretty late, so I think that'll work nice | |
| 15:59:04 | melwitt | agreed | |
| 16:09:32 | mriedem | ooo i broke nova-lxd too https://review.openstack.org/#/q/I751fcb7532679905c4279744919c6cce84a11eb4 | |
| 16:10:44 | mriedem | odyssey4me: that's awesome that nova can unwittingly break nova-lxd and other out of tree virt drivers, which then in turn breaks OSA | |
| 16:11:10 | mriedem | odyssey4me: i'm sort of surprised that OSA's voting jobs don't exclude out of tree drivers | |
| 16:11:15 | sean-k-mooney | mriedem: isnt there a thirdpart ci for nova-lxd | |
| 16:11:26 | mriedem | sean-k-mooney: no, nova-lxd is not in tree | |
| 16:12:17 | sean-k-mooney | mriedem: yes but i would have expected there to be a non gating thrid party ci to test it even when its out of tree | |
| 16:12:33 | mriedem | why would we care? | |
| 16:12:45 | mriedem | if you're out of tree, you're out of tree, and we don't block in-tree changes because of that | |
| 16:12:57 | mriedem | best we do at times is put something in the ML as a heads up for known internal interface changes | |
| 16:14:55 | bauzas | that remembers me some pg discussion... | |
| 16:14:58 | sean-k-mooney | not run by nova run by the maintiners of nova-lxd e.g. canonical | |
| 16:15:17 | bauzas | which I think we cleary made the statement that non-supported things for a project are potentially subject to break | |
| 16:15:32 | mriedem | bauzas: we have jobs we can run for pg testing if we ant | |
| 16:15:33 | mriedem | *want | |
| 16:15:34 | bauzas | hence other projects gating on that project shouldn't really support that too | |
| 16:15:36 | sean-k-mooney | mriedem: oh im not expecting nova to block in tree change i just expcting that nova-lxd team could benifit form know that its broken | |
| 16:15:39 | mriedem | there is a neutron job in the experimental queue that runs with pg | |
| 16:16:09 | mriedem | sean-k-mooney: nova-lxd team can listen on nova changes, run jobs and post results for failures somewhere if they want to detect them early | |
| 16:17:06 | bauzas | mriedem: I'm not saying it's impossible | |
| 16:17:16 | bauzas | mriedem: just that we broke ceilometer once | |
| 16:17:36 | bauzas | because ceilo was gating something we don't test | |
| 16:17:44 | mriedem | sure, i'm sure ceilometer broke us once indirectly too when they were part of tempest, 3 years ago | |
| 16:18:14 | bauzas | and the result was like a best-effort fix and a summit discussion that led to "come and help us make pg first-grade if your production runs on something we don't test" | |
| 16:18:34 | mriedem | there is nothing 2nd grade about pg wrt nova | |
| 16:18:51 | bauzas | I think we're diverting anyway | |
| 16:19:18 | bauzas | I just tried to explain that I feel you shouldn't blame yourself for breaking ansible if they gate on something we don't test | |
| 16:19:26 | dansmith | mriedem: this seems like a legit "stop the bleeding" patch for stable.. I saw you reviewed it once, but.. are you cool with it? https://review.openstack.org/#/c/543569 | |
| 16:19:34 | bauzas | we can certainly fix that tho | |
| 16:19:37 | mriedem | bauzas: i don't really blame myself :) | |
| 16:19:41 | sahid | mriedem: if you have a moment that one looks ready and important enough for some use-cases https://review.openstack.org/#/c/553072/ | |
| 16:19:44 | mriedem | sucks for odyssey4me though | |
| 16:20:05 | bauzas | mriedem: I agree, and that requires a fix | |
| 16:20:05 | mriedem | jesus, did the red hat team bug meeting just end? | |
| 16:20:22 | bauzas | mriedem: nah, not bugs | |
| 16:20:35 | bauzas | but yes, meeting ended | |
| 16:21:23 | mriedem | dansmith: i've just been putting off going through it again because it's hairy on stable | |
| 16:21:31 | mriedem | i'm not opposed to it no | |
| 16:21:33 | dansmith | it's big, | |