| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-04 | |||
| 06:27:30 | gmann | oomichi: updated https://review.openstack.org/#/c/451673/ | |
| 06:39:09 | openstackgerrit | Dan Peschman proposed openstack/nova master: Add uuid to Service model https://review.openstack.org/453025 | |
| 06:42:38 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add a removeFloatingIp example https://review.openstack.org/453026 | |
| 06:45:10 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: List/show all server migration types https://review.openstack.org/407237 | |
| 06:45:20 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: Specify keymap on server boot https://review.openstack.org/448830 | |
| 06:45:35 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: Abort Cold Migration https://review.openstack.org/334732 | |
| 06:58:41 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Add project/user association to placement https://review.openstack.org/453030 | |
| 07:09:45 | openstackgerrit | Sergey Nikitin proposed openstack/nova-specs master: TinyFix: Changed type of CPU ID from 'String' to 'Integer' in diagnostics spec https://review.openstack.org/445855 | |
| 07:13:52 | snikitin_ | johnthetubaguy, jaypipes: Hi guys! You approved my little fix in diagnostics spec but I had to reupload it because of pep8 error. Could you please fast reapprove it? https://review.openstack.org/#/c/445855 | |
| 07:17:25 | openstackgerrit | Sihan Wang proposed openstack/nova master: Show quota detail when inject file quota exceeds https://review.openstack.org/453040 | |
| 07:23:30 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Convert consoles code to use objects framework https://review.openstack.org/453041 | |
| 07:27:24 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add api sample tests for security group rules https://review.openstack.org/452055 | |
| 07:28:46 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add api sample tests for security group rules https://review.openstack.org/452055 | |
| 08:22:17 | lyarwood | mdbooth: https://review.openstack.org/#/c/452938/ - hackaround for an encrypted nfs volume corruption bug if you get time today | |
| 08:30:02 | johnthetubaguy | sfinucan: do you have context on this, I have some dumb questions: https://review.openstack.org/#/c/361140 | |
| 08:33:34 | sfinucan | johnthetubaguy: looking | |
| 08:33:56 | sfinucan | johnthetubaguy: Sure do. What's up? | |
| 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_ | 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:49:46 | snikitin_ | derect affinity | |
| 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 | sfinucan | At the moment, scheduling works by identifying hosts with enough free CPUs and SR-IOV devices (no knowledge of NUMA yet) | |
| 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: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 DELETE RP inventories https://review.openstack.org/452708 | |
| 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: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 | |