| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-04 | |||
| 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/ | |
| 12:29:01 | bauzas | johnthetubaguy: too ^ | |
| 12:31:47 | johnthetubaguy | bauzas: hopefully will get there, mostly just cleaning up the queue this morning | |
| 12:32:10 | bauzas | johnthetubaguy: where are we discussing in the PTG etherpad about https://review.openstack.org/#/c/381912/10/specs/pike/approved/strict_isolation_of_group_of_hosts_for_image_and_flavor.rst ? | |
| 12:32:16 | bauzas | johnthetubaguy: I don't remember that | |
| 12:32:31 | johnthetubaguy | bauzas: search for the patch number, you should find it | |
| 12:33:29 | bauzas | johnthetubaguy: FWIW, it's an old discussion | |
| 12:38:56 | snikitin_ | jaypipes: I don't know why bot after your reapprove gate jobs weren't started. https://review.openstack.org/#/c/445855/ maybe try again with +2 | |
| 12:39:13 | snikitin_ | ? | |
| 12:41:48 | sdague | snikitin_: it needs both a +2 and a +W | |
| 12:42:22 | snikitin_ | sdague, thanks! | |
| 12:59:16 | johnthetubaguy | bauzas: sfinucan: can I ask you about this one: https://review.openstack.org/#/c/438787 | |
| 12:59:26 | sfinucan | johnthetubaguy: Hit me | |
| 12:59:36 | johnthetubaguy | bauzas: sfinucan: why can't we use the existing image property, basically? | |
| 13:00:19 | sfinucan | johnthetubaguy: I think the existing property refers to a different attribute of the emulated VGA dev | |
| 13:00:55 | johnthetubaguy | it seems to be video ram vs vga ram, they seem like the same thing to me | |
| 13:01:13 | bauzas | johnthetubaguy: AFAICU, that seems to be a separate property | |
| 13:01:28 | bauzas | looking at https://libvirt.org/formatdomain.html | |
| 13:01:29 | sfinucan | johnthetubaguy: That should be in the spec. If you haven't done it already, there should probably be a comment to the same | |
| 13:01:31 | johnthetubaguy | but why are they different? what does it mean? | |
| 13:01:43 | sfinucan | They are different properties though. Lemme find the QEMU docs | |
| 13:02:16 | sfinucan | johnthetubaguy: | |
| 13:02:18 | sfinucan | johnthetubaguy: https://www.ovirt.org/documentation/draft/video-ram/ | |
| 13:02:28 | sfinucan | vgamem is allocated within ram. Minimum ram size, as enforced by QEMU regardless the command line settings, is 2 * vgamem. vram is allocated separately. | |
| 13:02:38 | bauzas | johnthetubaguy: https://libvirt.org/formatdomain.html#elementsVideo | |
| 13:02:47 | bauzas | what sfinucan said | |
| 13:03:12 | bauzas | "Attribute ram ( since 1.0.2) specifies the size of the primary bar, while the attribute vram specifies the secondary bar size. If ram or vram are not supplied a default value is used. The ram should also be rounded to power of two as vram. There is also optional attribute vgamem (since 1.2.11) to set the size of VGA framebuffer for fallback mode of QXL device | |