| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-13 | |||
| 20:39:42 | bauzas | gibi: no worries, you said it's a substantial amount of work | |
| 20:39:56 | bauzas | gibi: I guess it's worth it for me to help you if I can | |
| 20:40:15 | bauzas | gibi: the only problem is that I was a bit on and off last cycle, so I need to ramp up a little bit | |
| 20:42:39 | gibi | bauzas: as soon as I catch up with the rebase you can help a lot by reviewing the series and finding gaps we missed | |
| 20:43:02 | gibi | bauzas: until that if you have any questions about the current solution then I'm happy to help | |
| 20:45:44 | bauzas | gibi: sure, reviewing is one thing I can surely do | |
| 20:47:06 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix docs and add functional test for AggregateMultiTenancyIsolation https://review.openstack.org/601835 | |
| 20:53:19 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add post-test hook for testing evacuate https://review.openstack.org/602174 | |
| 20:53:24 | gibi | bauzas: this is the complication in the claim code path that I feel will cause trouble in move operations https://github.com/openstack/nova/blob/d8004bddaea167f85d5940e586cb5c9707adb278/nova/scheduler/client/report.py#L1820-L1827 | |
| 20:54:13 | gibi | bauzas: fortunately it seems we only hit this in evacuate case | |
| 20:54:27 | gibi | bauzas: as the rest of the move uses migration_uuid on the sorce host | |
| 20:55:39 | bauzas | looking | |
| 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 | bauzas | \o/ | |
| 21:07:46 | efried | oh - you're asking for some form of /resource_provider/{u}/allocations where we get a subtree? | |
| 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 | bauzas | you know, if you have teeth problem, I can help you :p | |
| 21:09:21 | efried | and, for that matter, sharing providers | |
| 21:09:41 | bauzas | in my case, for the nested RPs | |
| 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:09:54 | bauzas | not for shared | |
| 21:10:25 | gibi | bauzas: this is where the spec https://review.openstack.org/#/c/597601/ comes into picture | |
| 21:10:25 | efried | "not for shared" - yes, for shared too. If you had any. Which you kinda shouldn't. | |
| 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 | gibi | bauzas: will GPUs use granular requet groups? | |
| 21:11:39 | bauzas | naichuans: FWIW, I'm gonna creating a vgpu-stein BP | |
| 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 | |