| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-03 | |||
| 20:36:53 | mriedem | melwitt: can i have no opinion? | |
| 20:37:07 | melwitt | mriedem: of course | |
| 20:49:42 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP encryptors: Do not overwrite file volumes on attach https://review.openstack.org/452938 | |
| 20:49:54 | lyarwood | melwitt: ^ hackaround for the encrypted nfs volume corruption bug if you get time today | |
| 20:50:41 | melwitt | lyarwood: cool, thanks for the heads up | |
| 20:50:52 | lyarwood | mriedem: thanks for the heads up re the stable bugfixes btw, I'll queue them up for the morning | |
| 20:51:27 | mriedem | mordred: createBackup API has the same issue :) | |
| 20:54:33 | dansmith | sdague: instance_uuid would suck measurably more, IMHO | |
| 21:02:05 | openstackgerrit | Anusha Unnam proposed openstack/nova master: Add description to policies in servers.py https://review.openstack.org/451966 | |
| 21:04:25 | mriedem | wow, nova backup does not print out the actual image id for the created snapshot image | |
| 21:04:31 | mriedem | so i guess that's just an exercise for the user | |
| 21:04:53 | mriedem | melwitt: ^ have you ever seen anyone propose a change for that in novaclient? | |
| 21:05:36 | melwitt | mriedem: I haven't but to be honest I haven't been paying attention to novaclient changes in awhile | |
| 21:07:40 | dansmith | mriedem: backup is broken for certain things, right? like bfv instances? | |
| 21:07:47 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Remove Location header from createImage and createBackup response (spec) https://review.openstack.org/452951 | |
| 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 | mriedem | https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L527 | |
| 22:19:42 | dansmith | mriedem: aye | |
| 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 | gigabytes=-1 | |
| 04:48:59 | vks1 | ram=-1 | |
| 04:48:59 | vks1 | #cores=50 | |
| 04:48:59 | vks1 | instances=-1 | |
| 06:25:57 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: ix api-ref for create servers response https://review.openstack.org/451673 | |
| 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: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_ | 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) | |