| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-14 | |||
| 11:42:33 | alex_xu | lyarwood: gibi https://review.opendev.org/#/c/694063/7/specs/ussuri/approved/virt-bfv-instance-rescue.rst@76 | |
| 12:14:29 | etingof | o/ do we have a JSON schema for whatever is exposed through Nova metadata service? I am particularly interested in network_data.json | |
| 12:15:34 | openstackgerrit | Luyao Zhong proposed openstack/nova-specs master: support live migration with virtual persistent memory https://review.opendev.org/695863 | |
| 12:23:54 | sean-k-mooney | dansmith: efried i deployed https://review.opendev.org/#/c/699554/2 and installed the required version fo the sdk and cyborg client | |
| 12:24:07 | sean-k-mooney | it looks like there are still issue however http://paste.openstack.org/show/788372/ | |
| 12:25:37 | sean-k-mooney | it looks like everything on the placement side is fine but its failing to boot a vm with "AttributeError: \'RequestSpec\' object has no attribute \'root_required\'\n\n'" | |
| 12:31:24 | huaqiang | hello stephenfin. I hope you enjoyed your vacation | |
| 12:32:21 | huaqiang | I also want to invite your to review https://review.opendev.org/#/c/668656/ | |
| 12:34:26 | huaqiang | we have had some disscution especially on how to create a mixed instance, and Alex have put those dicussion links to the update of the spec | |
| 12:34:34 | huaqiang | I hope to get your comments. | |
| 12:37:00 | gibi | alex_xu: responded. If you are OK with the microversion then feel free to +A, I will +A myself if lyarwood or dansmith state that the microversion is intentional | |
| 12:39:15 | lyarwood | gibi / alex_xu ; apologies just back from a long lunch, yeah it's intentional, I'll add a comment now. | |
| 12:39:25 | gibi | lyarwood: cool thanks | |
| 12:47:13 | brinzhang | This bug fix is ready to review, if you have free time, please review https://review.opendev.org/#/c/580271/ | |
| 12:48:59 | openstack | bug 1663456 in OpenStack Compute (nova) "Field 'updated_at' always 'None' when show aggregate" [Low,In progress] https://launchpad.net/bugs/1663456 - Assigned to Brin Zhang (zhangbailin) | |
| 12:48:59 | brinzhang | it's bug 1663456 | |
| 12:54:07 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: Boot from volume instance rescue https://review.opendev.org/694063 | |
| 12:54:19 | lyarwood | ^ addressed the commit nit btw | |
| 12:55:34 | sean-k-mooney | dansmith: efried: ok so the cyborg series just need to be rebased on https://review.opendev.org/#/c/699050/ | |
| 12:56:31 | sean-k-mooney | well that is merges so rebaseing on master would be enough | |
| 13:00:24 | gibi | lyarwood: +Ad the spec | |
| 13:00:31 | gibi | lyarwood: thanks for the confirmation | |
| 13:03:07 | lyarwood | gibi: awesome thanks :) | |
| 13:19:56 | sean-k-mooney | stephenfin: can you review this when you get a chance https://review.opendev.org/#/c/701601/ | |
| 13:34:33 | openstackgerrit | Merged openstack/nova-specs master: Boot from volume instance rescue https://review.opendev.org/694063 | |
| 13:48:08 | stephenfin | huaqiang: As with luyao, if you can ask me again tomorrow I'll try get to it. Too much to do today :( | |
| 13:57:27 | lyarwood | efried: https://review.opendev.org/#/c/694033/ - The spec for this has now merged if you're able to look again today, thanks in advance. | |
| 14:01:49 | stephenfin | sean-k-mooney: done | |
| 14:04:04 | huaqiang | stephenfin: Understand. Don't worry. I will connect you later :) | |
| 14:04:18 | stephenfin | cool, thanks :) | |
| 14:16:34 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove unused nova-network objects https://review.opendev.org/697156 | |
| 14:16:35 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove now unnecessary nova-network workaround https://review.opendev.org/702440 | |
| 14:17:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove now unnecessary nova-net workaround https://review.opendev.org/702440 | |
| 14:17:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove unused nova-network objects https://review.opendev.org/697156 | |
| 14:18:58 | stephenfin | gibi: I addressed your comments in https://review.opendev.org/#/c/696516/ Think you could revisit at some point? | |
| 14:19:57 | stephenfin | gibi: Also, I think I addressed mriedem's concerns on https://review.opendev.org/#/c/696745/ but we can have dansmith look at it to make sure (since he was of the same opinion), if that helps | |
| 14:40:41 | openstackgerrit | sean mooney proposed openstack/os-vif master: [DNM]test composing devstack_local_conf sections https://review.opendev.org/702446 | |
| 14:41:57 | sean-k-mooney | stephenfin: if ^ works ill squash it into the previous patch but im not sure that we can split devstack_local_conf defination across the job inheritance or if we can if that extends to the post-config: section too | |
| 14:42:09 | sean-k-mooney | so i expect that might fail | |
| 14:45:25 | stephenfin | ack | |
| 14:46:06 | ganso | this spec exists https://blueprints.launchpad.net/nova/+spec/allow-disabling-cpu-flags but I don't see it handling previously existing VMs, only newly created VMs so that they get the correct flags set in the instance XML. Is there any work in-progress to minimize the impact around this? or any known workaround besides having to edit every instance XML manually? | |
| 14:46:06 | ganso | Hello folks. I have a question about the impact of security vulnerability upgrades to previously existing VMs. I have a customer that after upgrading the kernel to a newer version that supressed cpu flags ended up not being able to turn their VMs back on because qemu wouldn't allow unless the flags are specifically disabled in the XML. I believe this is something we will see happen several times in the future so it will be a recurrent impact. I see | |
| 14:47:12 | stephenfin | ganso: kashyap might be able to help you with that, if they're around ^ | |
| 14:47:17 | kashyap | Already reading :-) | |
| 14:48:11 | kashyap | ganso: Even if you edit every instance XML manually, which we don't recommend, you do know that it will go away once you reboot the guest? | |
| 14:49:13 | kashyap | ganso: I haven't gotten around to implementing that BP, got buried in other stuff. But good news, there's a valid workaround: | |
| 14:49:17 | ganso | kashyap: I wasn't aware of that, thanks. It will go away in the sense that every time it the VM is rebooted nova will overwrite the cpu flags in the XML with what it has defined? | |
| 14:49:41 | kashyap | ganso: QEMU has added newer variants of CPU models (with affected flags disabled) that you can directly specify with Nova | |
| 14:50:40 | kashyap | ganso: So, for the recent "TSX" vulnerability fiasco ... | |
| 14:51:34 | kashyap | ganso: ... QEMU / libvirt has added *-noTSX CPU models. | |
| 14:52:21 | kashyap | ganso: E.g. on my Fedora host, running qemu-system-x86-4.2.0-2.fc30.x86_64: | |
| 14:53:07 | kashyap | x86 Broadwell-noTSX (alias of Broadwell-v2) | |
| 14:53:07 | kashyap | $> qemu-system-x86_64 -cpu help | egrep *.noTSX* | |
| 14:53:10 | kashyap | x86 Broadwell-noTSX-IBRS (alias of Broadwell-v4) | |
| 14:53:13 | kashyap | x86 Cascadelake-Server-noTSX (alias of Cascadelake-Server-v3) | |
| 14:53:16 | kashyap | x86 Haswell-noTSX (alias of Haswell-v2) | |
| 14:53:19 | kashyap | x86 Haswell-noTSX-IBRS (alias of Haswell-v4) | |
| 14:53:22 | kashyap | x86 Icelake-Client-noTSX (alias of Icelake-Client-v2) | |
| 14:53:25 | kashyap | x86 Icelake-Server-noTSX (alias of Icelake-Server-v2) | |
| 14:53:28 | kashyap | x86 Skylake-Client-noTSX-IBRS (alias of Skylake-Client-v3) | |
| 14:53:31 | kashyap | x86 Skylake-Server-noTSX-IBRS (alias of Skylake-Server-v3) | |
| 14:53:34 | kashyap | --- | |
| 14:53:49 | ganso | kashyap: cool, so the new name needs to get to the instance XML | |
| 14:53:56 | kashyap | ganso: So if you've got libvirt/QEMU versions with noTSX stuff (confirm by running the above version), then you can use those model names in your nova.conf [libvirt] section | |
| 14:54:13 | kashyap | ganso: Yes, indeed. | |
| 14:54:36 | ganso | kashyap: ok, replacing them in nova.conf [libvirt] section will only affect new VMs or previously existing ones as well? | |
| 14:54:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: nova-net: Remove unused nova-network objects https://review.opendev.org/697156 | |
| 14:54:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove 'nova.image.api' module https://review.opendev.org/702451 | |
| 14:55:21 | kashyap | ganso: Yes, it will affect — once you reboot the Compute node — _all_ the VMs re-started on that node | |
| 14:55:41 | kashyap | cpu_models = Haswell-noTSX-IBRS | |
| 14:55:41 | kashyap | cpu_mode = custom | |
| 14:55:41 | kashyap | [libvirt] | |
| 14:55:41 | kashyap | You'd want something like: | |
| 14:55:42 | kashyap | cpu_model_extra_flags = pcid,spec-ctrl,ssbd,md-clear | |
| 14:56:18 | kashyap | ganso: And also, related reference: https://docs.openstack.org/nova/latest/admin/mitigation-for-Intel-MDS-security-flaws.html | |
| 14:57:18 | kashyap | Speaking of which ... /me should probably one for the not-so-fresh-off-the-oven "TAA" (TSX Asynchronous Abort) CVE | |
| 14:57:45 | ganso | kashyap: thanks for the clarification! :D | |
| 14:58:20 | ganso | kashyap: I will talk to the customer about this approach, should get the impact sorted out | |
| 14:58:21 | kashyap | No problem; this whole space is a barrel of cockroaches | |
| 14:59:13 | dansmith | sean-k-mooney: yep (re: the rebase) | |
| 15:00:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: pre-commit: Use Python 3 to run checks https://review.opendev.org/702453 | |
| 15:01:31 | sean-k-mooney | it look like some fo the cyborg code is still pending by the way | |
| 15:03:47 | sean-k-mooney | specificly https://review.opendev.org/#/c/698190/ for the deploables v2 api although i dont know if that is needed for nova integration | |
| 15:04:20 | sean-k-mooney | the devices v2 patches merged today https://review.opendev.org/#/c/695648/ | |
| 15:05:24 | stephenfin | efried, bauzas: Since you reviewed the original, could you blast this through? It's hurting me when working on some of the newly Python 3-only files we now have https://review.opendev.org/702453 | |
| 15:08:49 | efried | sean-k-mooney: would you +1 that ^ and I'll fast approve? | |
| 15:09:38 | efried | lyarwood: can you please tag the commit message for https://review.opendev.org/#/c/694033/ with the `blueprint xxx-xxx-xxx` magic? | |
| 15:10:14 | sean-k-mooney | the precommit change yes runnign it with python3 makes sesne give me a sec and ill add a link in a comment to the relevent docs | |
| 15:10:28 | lyarwood | efried: ack, I'll do that now. | |
| 15:10:46 | efried | lyarwood: when was the blueprint set to Definition:Approved and by whom? | |
| 15:11:20 | efried | (I thought there used to be a History button, but I must be thinking of something else) | |
| 15:11:51 | efried | sean-k-mooney: yes, cyborg series should be rebased to use root_required | |
| 15:12:33 | efried | okay, I think I'm caught up | |
| 15:12:35 | lyarwood | efried: I'm not sure about https://blueprints.launchpad.net/nova/+spec/virt-rescue-stable-disk-devices but https://blueprints.launchpad.net/nova/+spec/virt-bfv-instance-rescue for this change and spec still needs approval | |
| 15:13:28 | lyarwood | efried: ah found the email, MattR approved virt-rescue-stable-disk-devices | |
| 15:13:44 | efried | FYI nova, we've merged merged https://review.opendev.org/#/c/701792/ which should get rid of the "multiple possible networks" tempest errors we've been seeing a lot of lately. If you see more of them, let me know, cause the fix should be simple. | |
| 15:13:46 | efried | stephenfin: ^ | |
| 15:14:01 | efried | "we've merged merged"? #uncaffeinated | |
| 15:14:15 | artom | Question about bug triage | |
| 15:14:28 | artom | " Close as "invalid" if it is a support request or feature request." from https://wiki.openstack.org/wiki/Nova/BugTriage | |