| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-03 | |||
| 21:07:55 | dansmith | tbh I kinda relegated it into an old usage scenario | |
| 21:08:12 | mriedem | flwang tried fixing bfv with backup years ago, but we blocked it | |
| 21:08:27 | dansmith | yeah | |
| 21:10:09 | openstackgerrit | Sarafraj Singh proposed openstack/nova-specs master: WIP: Replace live migration steps and delays with memory iteration logic https://review.openstack.org/443339 | |
| 21:10:58 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Remove Location header from createImage and createBackup response (spec) https://review.openstack.org/452951 | |
| 21:11:08 | mriedem | mordred: sdague: ^ the spec | |
| 21:11:49 | mriedem | dansmith: i bet we don't mention that limitation in the api ref for createBackup either | |
| 21:12:21 | dansmith | I kinda wish we didn't mention it at all :) | |
| 21:12:30 | mriedem | like the os-pci API? | |
| 21:12:34 | mriedem | which reminds me... | |
| 21:13:44 | mriedem | nice, this is the message you get back with the 400 in that case, "The request is invalid." | |
| 21:14:00 | mriedem | it should also kick you in the balls while it's being helpful | |
| 21:14:34 | dansmith | it logs something relevant, but yeah, no help for the user | |
| 21:15:20 | mriedem | logs something for the admin to check when he gets the support ticket | |
| 21:19:44 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove unused migrate_data kwarg from virt driver destroy() method https://review.openstack.org/452958 | |
| 22:02:36 | mordred | mriedem: awesome | |
| 22:03:25 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: Separate the releasenotes guide from the code-review section https://review.openstack.org/451870 | |
| 22:04:25 | mordred | mriedem: the impacts are awesome | |
| 22:04:33 | mriedem | None? | |
| 22:06:41 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Document and provide useful error message for volume-backed backup https://review.openstack.org/452970 | |
| 22:08:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: move createBackup to server-actions https://review.openstack.org/452971 | |
| 22:16:19 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: List instances using Searchlight (spec) https://review.openstack.org/441692 | |
| 22:18:22 | dtp | nova/objects/service.py/Service.obj_make_compatible_from_manifest doesn't seem to be called from anywhere within nova; is it still used? | |
| 22:19:16 | mriedem | dtp: i believe that's used in the oslo.versionedobjects library | |
| 22:19:21 | mriedem | so it's probably an override in nova | |
| 22:19:42 | dansmith | mriedem: aye | |
| 22:19:42 | mriedem | https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L527 | |
| 22:19:56 | dtp | roger; thanks | |
| #openstack-nova - 2017-04-04 | |||
| 04:48:29 | vks1 | ConfigFileValueError: Value for option instances is not valid: invalid literal for int() with base 10 . Getting this error. I have set nova.conf like this: | |
| 04:48:58 | vks1 | [quota] | |
| 04:48:59 | vks1 | instances=-1 | |
| 04:48:59 | vks1 | #cores=50 | |
| 04:48:59 | vks1 | ram=-1 | |
| 04:48:59 | vks1 | gigabytes=-1 | |
| 06:25:57 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: api-ref: fix os-extended-volumes:volumes_attached in servers responses https://review.openstack.org/449809 | |
| 06:25:57 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: ix api-ref for create servers response https://review.openstack.org/451673 | |
| 06:27:18 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Fix api-ref for create servers response https://review.openstack.org/451673 | |
| 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? | |