Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-13
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
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
22:05:17 bauzas mriedem: cool, I know what to do for next week
22:05:52 mriedem the functional test for reshaper mocks out the reshape code in the test itself; i suggested to efried that we move that to a fake virt driver - and if we did that, then i think we can just bolt the post-reshape scheduler request onto the same test
22:06:18 mriedem maybe we don't need to move that into a fake virt driver, idk
22:06:29 mriedem but would be nice if we can just add a few lines to that existing test to see if this passes or fails
22:07:24 bauzas mriedem: lemme test that
22:07:51 mriedem bauzas: https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/tests/functional/test_servers.py#L1835
22:08:16 mriedem yeah so at the end, just try to create an instance on that host with vgpu and see if it blows up
22:08:33 mriedem if it fails, we can assert it should fail until https://review.openstack.org/#/q/topic:use-nested-allocation-candidates+(status:open+OR+status:merged) fixes it
22:08:37 mriedem and rebase those on top

Earlier   Later