| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-14 | |||
| 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 | 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: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: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 | $> qemu-system-x86_64 -cpu help | egrep *.noTSX* | |
| 14:53:07 | kashyap | x86 Broadwell-noTSX (alias of Broadwell-v2) | |
| 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 | You'd want something like: | |
| 14:55:41 | kashyap | [libvirt] | |
| 14:55:41 | kashyap | cpu_mode = custom | |
| 14:55:41 | kashyap | cpu_models = Haswell-noTSX-IBRS | |
| 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 | |
| 15:14:30 | artom | Is that a thing we do? | |
| 15:14:35 | efried | lyarwood: would you mind adding a note for that. But... why are there two blueprints? (I haven't actually *read* anything, so maybe it's obvious, but lead me by the nose here) | |
| 15:14:56 | artom | Specifically about https://bugs.launchpad.net/nova/+bug/1859403 | |
| 15:14:56 | openstack | Launchpad bug 1859403 in OpenStack Compute (nova) "The instance needs to supports dongle devices" [Wishlist,New] | |
| 15:14:56 | efried | artom: this actually came up last week and I didn't consult that wiki page. | |
| 15:15:29 | openstackgerrit | Lee Yarwood proposed openstack/os-traits master: Add COMPUTE_BFV_RESCUE trait https://review.opendev.org/694033 | |
| 15:15:36 | artom | I set it to wishlist, is that it? Or since we know what it is (wishlist), we can set it to Triaged as well to remove it from filters/lists | |
| 15:15:39 | efried | dansmith opened a pro forma bug for something, trying to remember... | |
| 15:16:19 | dansmith | "opened a pro forma bug....against his will" | |
| 15:18:03 | efried | yeah yeah | |
| 15:18:07 | efried | dansmith: this one rite? https://bugs.launchpad.net/nova/+bug/1858877 | |
| 15:18:07 | openstack | Launchpad bug 1858877 in OpenStack Compute (nova) "Silent wasted storage with multiple RBD backends" [Wishlist,Confirmed] | |
| 15:18:18 | dansmith | yar | |
| 15:18:23 | efried | Since artom points to an actual document saying we should close as Invalid, Ima do that. | |
| 15:18:29 | efried | and artom, yeah, do same with yours. | |
| 15:18:30 | dansmith | lol | |
| 15:18:38 | artom | efried, well, wikis are fickle things | |
| 15:18:47 | efried | I was looking for any excuse | |
| 15:18:58 | artom | I could edit that to say every time a wishlist is filed, we need to call POTUS and get his approval | |
| 15:19:11 | efried | I think if we get to 100 open bugs, the stay-puft marshmallow man shows up or something. | |
| 15:19:20 | efried | Then we have to cross the streams, marshmallow everywhere, big mess. | |
| 15:19:24 | gibi | stephenfin: I'm +2 on https://review.opendev.org/#/c/696516/ based on your answers | |
| 15:19:42 | stephenfin | gibi: thanks | |