| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-14 | |||
| 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 | |
| 15:19:47 | artom | efried, follow-up question then - if we close wishlist items as invalid, how do we expect folks to file them? | |
| 15:20:01 | efried | blueprints, right? | |
| 15:20:07 | artom | You're asking me? | |
| 15:20:30 | gibi | stephenfin: regarding the rename in https://review.opendev.org/#/c/696745/ I can be convinced both ways so I'm not voting now, sorry | |
| 15:20:46 | dansmith | yes, my point about my bug was that "nova does not support $thing" is not a bug, it's a feature request, hence blueprint at some point | |
| 15:20:54 | dansmith | however, we don't file blueprints for things we may or may not do in the future | |
| 15:21:05 | stephenfin | gibi: All good. Comes down to dansmith in that case | |
| 15:21:05 | dansmith | (nor should we) | |
| 15:21:09 | efried | Right, there seems to be a process gap there. | |
| 15:21:18 | dansmith | why? | |
| 15:21:23 | artom | IOW, if you have a feature request but aren't prepared to work on it yourself or pay someone to do it, your sool? | |
| 15:21:25 | artom | *you're | |
| 15:21:25 | efried | if there's a closed/wishlist bug, how do we ever "find" it and make a blueprint out of it. | |
| 15:21:26 | dansmith | we don't need to enumerate everything nova doesn't do, right? | |
| 15:22:02 | efried | of course, but a way to track "something nova doesn't do, but probably should, but nobody's going to work on it right now, but we don't really want to forget about it and *never* do it" | |
| 15:22:35 | efried | dansmith: I think your bug is a good example. You said it's something we probably want to do soonish. But who's gonna remember? | |
| 15:22:50 | artom | I mean, given the project/community dynamics, it'd be reasonable to say "sorry, if you want a thing but can't commit resources, it'll realistically never get done." | |
| 15:22:56 | artom | Not very welcoming, but reasonable | |
| 15:23:52 | dansmith | efried: if putting together that list is actually going to form a backlog that we chew through, then sure, but history tells me it will just become a wasteland of every crazy thing anyone ever thought of once | |