Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-13
20:56:53 bauzas gibi: oh shit, good catch
20:57:15 bauzas gibi: do we have any way to ask placement whether we have allocations in a subtree ?
20:57:33 bauzas something like ?root_rp=<>
20:58:11 gibi bauzas: nothing I know of
20:59:03 bauzas http://p6.storage.canalblog.com/62/41/721385/52520059.jpg
20:59:24 bauzas I miss sound
21:00:47 bauzas oh wait
21:01:10 bauzas gibi: https://github.com/openstack/nova/blob/d8004bddaea167f85d5940e586cb5c9707adb278/nova/scheduler/client/report.py#L1816 with some luck, we should get the allocation even if that's in a subtree
21:01:23 bauzas I shall start looking at the query
21:04:01 bauzas efried: btw. I said I have a patch up for resize/cold-migrate about allocations
21:04:02 gibi bauzas: one instance still only one allocation even if that allocation contains more than on RP including nested RPs. So from that API you will get the whole allocation
21:04:04 bauzas efried: see https://review.openstack.org/#/c/589085/
21:04:25 bauzas gibi: say it again
21:04:37 bauzas ah
21:05:03 bauzas gibi: I'll get N allocations against N inventories, right?
21:05:04 efried bauzas: Ack, I'm on that guy, thx
21:05:06 gibi bauzas: GET /allocations/<instance_uuid> returns the allocation of the instance that contains multiple RPs including nested one
21:05:34 gibi bauzas: yes. one consumer (the instance_uuid) mapped to a list of allocations
21:06:01 gibi bauzas: but you cannot tell placement only return a subset of those allocations
21:06:14 efried why would you want to do that?
21:06:26 gibi efried: I don't :)
21:06:31 bauzas gibi: I don't get why I would restrict
21:06:45 efried we're in violent agreement, then
21:06:51 gibi bauzas: then I missunderstood "22:57 < bauzas> gibi: do we have any way to ask placement whether we have allocations in a subtree "
21:06:53 bauzas gibi: if I'm getting all the allocations including the nested ones, that's perfect, nope?
21:07:21 gibi bauzas: I thought you only want to get the nested one. But sure you get all of them today
21:07:26 bauzas gibi: I meant I wanted to make sure we were getting all the allocations including the "nested" ones
21:07:40 gibi bauzas: then you are good with the today's API
21:07:41 bauzas then I think we're cool, no ?
21:07:46 efried oh - you're asking for some form of /resource_provider/{u}/allocations where we get a subtree?
21:07:46 bauzas \o/
21:07:51 bauzas efried: no
21:08:02 efried tbc, that route gives you all allocations on the provider (from all consumers)
21:08:22 bauzas efried: the context is, what do we need for nested RPs to be correctly scheduled
21:08:35 efried mm
21:08:37 bauzas efried: and gibi pointed out we were looking up allocations on some cases
21:08:43 efried mm
21:09:04 bauzas so I just wanted to make sure we were getting'em, including the ones that were against inventories on children
21:09:10 efried mm
21:09:21 efried and, for that matter, sharing providers
21:09:21 bauzas you know, if you have teeth problem, I can help you :p
21:09:41 bauzas in my case, for the nested RPs
21:09:54 bauzas not for shared
21:09:54 gibi bauzas: what you will not get from placement is the mapping between granular request groups in the a_c request and the allocation that fulfills that group
21:10:25 efried "not for shared" - yes, for shared too. If you had any. Which you kinda shouldn't.
21:10:25 gibi bauzas: this is where the spec https://review.openstack.org/#/c/597601/ comes into picture
21:10:26 bauzas nah, kidding
21:10:32 bauzas ok
21:11:11 bauzas gibi: ok, I'll look at the spec later in the day
21:11:39 bauzas naichuans: FWIW, I'm gonna creating a vgpu-stein BP
21:11:39 gibi bauzas: will GPUs use granular requet groups?
21:11:55 bauzas gibi: it will for NUMA affinity
21:12:18 gibi bauzas: then for NUMA you might hit the problem I describe in that spec
21:12:23 bauzas yup
21:12:50 bauzas for the simple case where VGPUs are on a child but other resources are on root RP, we're all good
21:13:05 bauzas provided I'm getting RPs that support both requesrs
21:13:22 efried gibi: Skimming the spec, I don't think it goes far enough, I'm afraid.
21:13:25 bauzas requests, ie. VGPU in one child that's necessarly on the root RP having enough resources
21:13:43 gibi efried: comments are very welcome :)
21:14:41 bauzas oh, awesome, there is already a vgpu-stein BP https://blueprints.launchpad.net/nova/+spec/vgpu-stein
21:14:49 bauzas naichuans: nevermind then my previous point
21:15:19 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: [Stable Only] Remove soft-deleted instances from quota_usages https://review.openstack.org/602459
21:18:07 efried gibi: If I wind up with more than one value in my 'contributes_to' list, I'm right back where I started not knowing which request group corresponds to which chunk of the response.
21:19:06 gibi efried: if you mean group_policy=None and two request groups end up fulfilled by the same RP then you are correct that still sucks
21:19:15 efried gibi: So
21:19:21 gibi efried: I forget about that case
21:19:30 efried The alternative you suggest at the end, breaking the allocation request up...
21:19:31 bauzas oh shit, I just realize that the next PTG will litterally be 1 week after Brexit, and I'm usually flying BA
21:19:35 bauzas that could become fun
21:19:48 efried if you do that keyed by request group instead, you're golden.
21:19:53 efried gibi: ^
21:20:14 efried Sucks to have to change the allocation request syntax, for sure, but there's no other complete solution.
21:20:52 gibi efried: good point. I will need to work on that spec
21:21:24 efried gibi: Even for a granular request you have the problem.
21:26:34 efried gibi: e.g. resources2=BW:100&resources3=BW:200&group_policy=none
21:26:50 efried today you might get back BW:300 from a single provider, which is :(
21:26:59 openstackgerrit Lee Yarwood proposed openstack/nova stable/ocata: [Stable Only] Remove soft-deleted instances from quota_usages https://review.openstack.org/570653
21:30:14 gibi efried: true
21:31:13 bauzas gibi: efried: that's the exact problem I hit for VGPU affinity, right?
21:31:30 bauzas if I want to have this NUMA node and that VGPU to be on the same tree
21:31:44 efried bauzas: It's less of a problem for VGPU, which is single unit
21:31:51 efried bauzas: Oh, no, that's a separate problem.
21:32:19 bauzas sorry, I learnt German and English at college, not Placement :p
21:53:13 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Re-proposes multiple vGPU types in libvirt https://review.openstack.org/602474
21:53:59 bauzas oh, we're not advertising on nova-specs changes ?
21:54:22 bauzas I mean, I don't openstackgerrit telling my spec
21:55:43 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Re-proposes multiple vGPU types in libvirt https://review.openstack.org/602474
21:56:54 bauzas mmm, strange but ok
21:58:34 openstackgerrit sean mooney proposed openstack/os-vif master: add support for generic tap device plug https://review.openstack.org/602384
21:59:06 bauzas mriedem: given what we said yesterday, shall we put a procedural -2 on https://review.openstack.org/#/c/599208/ and say we can't do it until https://review.openstack.org/#/q/topic:use-nested-allocation-candidates+(status:open+OR+status:merged) is merged ?
22:01:04 mriedem because once the vgpu is on the child provider, vgpu scheduling would be broken?
22:03:42 bauzas mriedem: yup
22:04:00 bauzas no valid hosts
22:04:15 bauzas since it wouldn't find any RP that fulfills the VGPU resource class
22:04:25 mriedem bauzas: i guess? alternatively, we should have a functional test that does the reshape and then tries to schedule to the vgpu in the child - which we said we wanted as part of the checklist for placement extraction
22:04:44 bauzas mriedem: yeah, I discussed that with gibi
22:04:55 bauzas mriedem: the functional test should see that
22:04:56 mriedem we do have functional tests for reshaper with the fake virt driver,
22:05:02 mriedem we just don't try to schedule to that host after the reshape
22:05:08 openstackgerrit Merged openstack/nova stable/rocky: Add functional test for affinity with multiple cells https://review.openstack.org/599731

Earlier   Later