| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-13 | |||
| 17:57:22 | edleafe | lyarwood: because the bug only is an issue when there aren't enough potential alternate hosts, right? | |
| 17:58:09 | lyarwood | edleafe: right and alternates listed are per instance | |
| 17:58:19 | lyarwood | alternates are listed* | |
| 17:59:40 | edleafe | lyarwood: so in the more common case where there are many more alternates available, we would be better off not adding hosts that may not have enoguh resources | |
| 18:00:16 | edleafe | lyarwood: only in the case where there aren't enough alternates should we include a host that is actively being built on | |
| 18:02:09 | lyarwood | edleafe: ah right, got it | |
| 18:04:41 | openstackgerrit | Eric Fried proposed openstack/os-traits master: Add OWNERSHIP_$SERVICE traits https://review.openstack.org/602160 | |
| 18:18:55 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add post-test hook for testing evacuate https://review.openstack.org/602174 | |
| 19:56:07 | mriedem | gibi: for your bw provider demo, osc commands take a wrap option, might be good to use - you're doing this at the summit too i think | |
| 20:03:24 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: delegate ovs plug to os-vif https://review.openstack.org/602432 | |
| 20:08:37 | stephenfin | mriedem, gibi: You can also use '-c' to show only the columns you care out and filter out the noise | |
| 20:13:52 | gibi | stephenfin, mriedem: thanks, it was a projector - laptop incompatibilty issue today about screen size. We will do better in Berlin :) | |
| 20:14:23 | mriedem | stephenfin: oh i know all about -c | |
| 20:14:31 | mriedem | and -f | |
| 20:20:57 | melwitt | our cycle highlights say live migration between neutron backends works https://github.com/openstack/releases/blob/master/deliverables/rocky/nova.yaml#L44-L46 | |
| 20:21:55 | melwitt | given that, I think filling in the gaps would be good ^ | |
| 20:38:50 | gibi | bauzas: if you want to try nested scheduling then this is the commit you need https://review.openstack.org/#/c/585672/ (our today's demo was based on it too) | |
| 20:38:58 | bauzas | gibi: awesome, ta | |
| 20:39:10 | bauzas | gibi: I first need to put my hands on some hardware | |
| 20:39:19 | openstackgerrit | Merged openstack/python-novaclient master: Follow the new PTI for document build https://review.openstack.org/602153 | |
| 20:39:21 | gibi | bauzas: please be aware that it is on an old base. I'm working on to rebase the whoel series | |
| 20:39:29 | bauzas | but that's something I'd like to do sooner than later clearly | |
| 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 | 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 | |