Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-04
08:34:32 johnthetubaguy sfinucan: so when I read the problem, I assumed I would see the reverse solution, let me try sketch that out
08:35:05 johnthetubaguy sfinucan: PCI whitelist tells Nova to only prefer NUMA affinity, because all the PCI devices are only on one NUMA node
08:35:22 johnthetubaguy that way the user doesn't need to worry themselves
08:36:27 johnthetubaguy sfinucan: I am guessing there is a use case that doesn't work for, but I am not seeing it myself
08:36:37 sfinucan johnthetubaguy: Is that a statement or a question? :)
08:36:59 sfinucan the PCI whitelist bit, that is
08:37:24 johnthetubaguy sfinucan: bit of both really, lol
08:37:39 johnthetubaguy snikitin_ I think this is your spec I am look at, if you are about ^
08:38:19 johnthetubaguy sfinucan: also, I wasn't sure why an image property was a good idea for this one, anyways I left some comments
08:38:38 sfinucan Hmm, so I don't get your question, but I can give you my tl;dr on that spec, if it would help
08:40:36 sfinucan In short, some people want to be able to use PCI devices even if they don't have NUMA affinity
08:41:20 sfinucan but we can't force that on everyone. The current behaviour is to fail if we can't get NUMA affinitized PCI devices and that behaviour should be retained
08:43:33 sfinucan johnthetubaguy: Hence, the need for configurable policies. I _think_ what you're saying is why not soften the requirements for everyone. That'd be great, until people start complaining about why the performance of their VMs has dropped (by 10-15%, based on data I've seen in the past) :)
08:43:56 johnthetubaguy sfinucan: no, no
08:44:09 johnthetubaguy sfinucan: I mean why configure it on the flavor, when its really a host property
08:49:44 sfinucan johnthetubaguy: Is it though?
08:49:46 snikitin_ derect affinity
08:49:46 snikitin_ johnthetubaguy, it's configured in flavor because it's influence on VM performance. For example you want to boot a high performance VM. You have a lot of hosts with different NUMA nodes and PCI devises. `strict` policy is guarantee you that scheduler will choose host with direct NUMA - PCI affinity. and then strict policy is guarantee you that from many PCI-NUMA combinations on current host nova compute will choose NUMA node and PCI device with
08:50:27 johnthetubaguy snikitin_: yeah, I think the mixed set of hosts is the main reason flavor wins
08:50:33 sfinucan It seems very workload specific. Some workloads will be impacted by the affinitization (or lack thereof)
08:51:15 johnthetubaguy snikitin_: sfinucan: the spec doesn't seems to cover scheduler filter or weights changes, I guess thats true right now, as its all picked on the host?
08:51:53 sfinucan johnthetubaguy: I can't say off the top of my head, but I think snikitin_ has WIP code up that might provide guidance on implementation
08:52:02 johnthetubaguy sfinucan: if you want the host to have SRIOV connections, and its only got NICs on one NUMA node, it feels like a host property
08:52:20 johnthetubaguy sfinucan: it just the spec normally would cover those details, and I don't see it mentioned really
08:52:52 openstackgerrit Sergey Nikitin proposed openstack/nova master: Added PIC NUMA policies https://review.openstack.org/390520
08:52:55 snikitin_ johnthetubaguy, here is PoC https://review.openstack.org/#/c/390520/
08:53:29 sfinucan johnthetubaguy: I don't think the spec is focussed on exposing any additional properties of SR-IOV devices. It would only manifest itself with scheduling
08:53:52 sfinucan If we wanted to expose the NUMA affinity etc. globally, resource providers would be the way forward. Different issue though
08:55:15 johnthetubaguy sfinucan: snikitin_: yeah, makes sense it doesn't impact the scheduler as such, because we just don't expose this stuff right now
08:55:46 snikitin_ johnthetubaguy: I don't changed numa_topology filter or weight code because both filter and nova compute use method 'fit_numa_topology' (or similar) to figure out if a VM can be booted on some host or not
08:55:46 sfinucan At the moment, scheduling works by identifying hosts with enough free CPUs and SR-IOV devices (no knowledge of NUMA yet)
08:56:10 sfinucan Once done, it'll try to fit the instance vCPUs onto the host pCPUs. If that's successful, it tries to get a free SR-IOV device and associate that with the guest
08:56:41 johnthetubaguy sfinucan: totally, that all makes sense
08:57:10 johnthetubaguy snikitin_: sfinucan: I wasn't sure why we need the image property as well as the flavor thing, is that just for completness?
08:57:19 snikitin_ yes
08:57:20 sfinucan johnthetubaguy: Sweet. So it's just the very last step that we're touching
08:57:27 sfinucan yup - that was my suggestion
09:00:14 openstackgerrit Jianghua Wang proposed openstack/nova-specs master: Support VGPU https://review.openstack.org/450122
09:02:55 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Placement doing claims https://review.openstack.org/437424
09:04:25 mdbooth johnthetubaguy: Is there a master list of priority specs?
09:05:41 johnthetubaguy mdbooth: not sure beyond what is in here: https://etherpad.openstack.org/p/pike-nova-priorities-tracking
09:06:17 mdbooth johnthetubaguy: I meant specifically for the spec review
09:06:18 mdbooth day
09:06:33 johnthetubaguy not that I know of
09:08:28 openstackgerrit Jianghua Wang proposed openstack/nova-specs master: Support VGPU https://review.openstack.org/450122
09:08:33 mdbooth johnthetubaguy: Do you have a strategy for finding important specs to review today?
09:09:21 johnthetubaguy currently got a gerrit dash up with all the open reviews, looking for the interesting looking ones, particularly ones with no votes or all positive votes
09:13:35 openstackgerrit Sergey Nikitin proposed openstack/nova master: Added PIC NUMA policies https://review.openstack.org/390520
09:27:45 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add snapshot id to the snapshot notifications https://review.openstack.org/453077
09:29:31 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add snapshot id to the snapshot notifications https://review.openstack.org/453077
09:53:02 openstackgerrit Silvan Kaiser proposed openstack/nova master: Switch Nova Quobyte volume driver to mount via systemd-run https://review.openstack.org/432344
09:59:35 openstackgerrit Jianghua Wang proposed openstack/nova-specs master: Support VGPU https://review.openstack.org/450122
10:05:30 openstackgerrit MarkMielke proposed openstack/nova master: Resource tracker should use Block Device Mappings https://review.openstack.org/430091
10:22:48 johnthetubaguy sfinucan: doing some cleanups, I am guessing you are not still pushing this one forward, or did we merge that somewhere else? https://review.openstack.org/#/c/406081/
10:23:02 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for GET RP inventories https://review.openstack.org/449765
10:23:02 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for DELETE RP inventories https://review.openstack.org/452708
10:23:03 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for PUT RP inventories https://review.openstack.org/452707
10:23:44 sfinucan johnthetubaguy: So that ties into the PCI spec you were reviewing earlier
10:24:57 sfinucan I thought image metadata was used to allow you to package an application up such that you could drop it into any cloud and it would just work
10:25:14 sfinucan ...assuming the cloud supported the required features
10:25:36 johnthetubaguy sfinucan: just clicked abandon on it as its been left unloved for 4 months, thats all
10:26:09 sfinucan johnthetubaguy: Yeah, that's fair :) I'm just curious what you think image metadata is for
10:27:02 sfinucan The above is why I said the PCI policies spec should have an image metadata aspect. Strict NUMA affinity could be a required attribute for a workload/application
10:27:39 johnthetubaguy sfinucan: its used for a heap of aweful things right now, and we don't define the contract anywhere, so I just hate it really
10:28:09 johnthetubaguy sfinucan: the use I like is specifying things that image requires in order to work correctly
10:29:59 johnthetubaguy sfinucan: but less is more when it comes to APIs, so if its something only the admin wants to control, I prefer not adding image metadata. For people who care we force them to add flavor extra specs now, rather than there being no way to change the defaults, possibly for zero gain.
10:30:27 sfinucan johnthetubaguy: Right. I think something like CPU thread or PCI policies falls into that category (the image would boot, but the combined performance impact could mean the application is not fit for purpose and therefore "broken")
10:30:36 sfinucan Hmm, yeah - that's the other perspective
10:31:30 sfinucan Long story short, that spec was applying the above idea to emulator thread policies. I don't care enough about it to pursue it though, heh
10:39:00 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Rewrap 'code-review' at ¬79 characters https://review.openstack.org/384960
11:07:54 kashyap sfinucan: Why rewrap?
11:08:00 kashyap It's at 72 now?
11:08:39 sfinucan kashyap: I think I had a change after it at one point?
11:08:47 kashyap Something like that. FWIW, it looks okay to me
11:08:52 kashyap I think I vaguely recall some list discussion
11:08:56 sfinucan It was in merge conflict so I just fixed it :)
11:09:59 kashyap Ah, okay :-)
11:48:38 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: Libvirt: Enable QEMU native LUKs handling https://review.openstack.org/437070
11:49:10 lyarwood mdbooth, kashyap ^ if you have spec review time today, I'm not 100% sure that we will have the required versions of QEMU and libvirt in the gate for Pike tbh
11:49:29 kashyap lyarwood: I did notice it, actually
11:49:41 kashyap lyarwood: Yes, we don't have the reqiured versions
11:50:20 lyarwood kashyap: right, but 17.04 will, I just don't think it's going to be used in the gate as it isn't LTS
11:50:22 kashyap lyarwood: We should really get that in-progress (over a year) DevStack plugin that lets us use QEMU / libvirt from Git (and newest releases / RCs) with Nova
11:50:42 lyarwood kashyap: link? I don't think I've seen that
11:51:17 kashyap lyarwood: https://review.openstack.org/#/c/108714/
11:51:35 lyarwood kashyap: thanks!
11:51:37 kashyap lyarwood: Err, scratch that -- that's the OLD one that was subimtted directly as part of DevStack
11:51:52 kashyap But the agreed decision was to make it a plugin
11:52:24 lyarwood kk
11:55:52 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: Libvirt: Enable QEMU native LUKs handling https://review.openstack.org/437070
11:56:17 mdbooth lyarwood: Will try to look today
11:56:44 lyarwood mdbooth: thanks
12:05:34 lyarwood kashyap: thanks for the link in the review btw
12:05:41 lyarwood kashyap: I'll check that out after lunch
12:06:17 kashyap lyarwood: Np. I'll be looking at that plugin again today, been meaning to but couldn't get around
12:07:01 jaypipes snikitin_: done
12:08:55 snikitin_ jaypipes, thanks!
12:12:31 openstackgerrit Silvan Kaiser proposed openstack/nova master: Removes getfattr from Quobyte Nova driver https://review.openstack.org/428646
12:15:45 openstackgerrit Silvan Kaiser proposed openstack/nova master: Removes getfattr from Quobyte Nova driver https://review.openstack.org/428646
12:28:52 bauzas jaypipes: you could be interested in https://review.openstack.org/#/c/446446/

Earlier   Later