| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-03 | |||
| 11:29:03 | openstackgerrit | Merged openstack/nova stable/queens: Block swap volume on volumes with >1 rw attachment https://review.opendev.org/662340 | |
| 11:43:11 | openstackgerrit | Boris Bobrov proposed openstack/nova master: Extract SEV-specific bits on host detection https://review.opendev.org/636334 | |
| 12:03:19 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Simplfy test setup for TestNovaMigrations* tests https://review.opendev.org/662434 | |
| 12:41:15 | aspiers | efried: after I implement the request filter thing for hw:mem_encryption and bbobrov addresses my feedback on his reviews, I think we'll be pretty close to being ready to hit the runway | |
| 12:58:33 | alex_xu | kashyap: after the instance live-migrated to _patched_ compute node, the guest won't get new cpu flag I thought, is it right? | |
| 12:59:45 | mnaser | alex_xu: afaik cpu flags will never change in a running host | |
| 12:59:52 | mnaser | s/host/vm/ | |
| 13:00:11 | alex_xu | mnaser: yea, that is what I'm thought also | |
| 13:01:08 | kashyap | alex_xu: If you live-migrate the guest to a patched node, it is as effective as a cold-reboot, as migration serves the same role as guest cold reboot of re-exec()ing QEMU. | |
| 13:01:46 | alex_xu | kashyap: but we copy same domain xml in the destination node? | |
| 13:02:54 | kashyap | alex_xu: Yeah; and libvirt tries very hard to not enable any newer QEMU's features on migration *without* explicit request. | |
| 13:03:28 | alex_xu | kashyap: that means you need to restart your guest to get the new feature | |
| 13:03:39 | alex_xu | s/new feature/new cpu feature/ | |
| 13:03:57 | alex_xu | on the _patched_ node | |
| 13:04:03 | kashyap | alex_xu: Yeah, the guest needs to be restarted at some point. | |
| 13:04:20 | kashyap | The point of live migration is that, it allows them to _start_ upgrading Compute nodes. | |
| 13:04:28 | kashyap | But we should actually determine all of this with a solid test: | |
| 13:05:03 | kashyap | (1) Two Compute nodes: Compute-Old and Compute-Patched | |
| 13:05:16 | kashyap | (2) Start a guest on Compute-Old, live-migrate it to Compute-Patched | |
| 13:06:42 | kashyap | (3) "See what happens" (the guest on -Patched should have same flags as on -Old) — until the guest is cold-rebooted | |
| 13:06:47 | alex_xu | i see your point | |
| 13:07:19 | kashyap | But in general, FWIW, I'd suggest live migrating when upgrading compute nodes | |
| 13:07:32 | alex_xu | i' ok with that | |
| 13:07:36 | kashyap | That's the reason why I took the live migration approach, and _then_ cold-start the guest. | |
| 13:07:45 | kashyap | That way, it reduces the impact | |
| 13:08:17 | alex_xu | another thought is I'm think we shouldn't suggest the way of upgrading compute nodes in that doc, the ugprading of compute nodes should be in the upgrade doc. | |
| 13:08:29 | alex_xu | but it should be fine | |
| 13:09:29 | kashyap | Yeah, I mentioned it for completeness' sake, as it made sense in that context. | |
| 13:10:34 | alex_xu | kashyap: I change to +2 | |
| 13:13:38 | kashyap | alex_xu: Thank you | |
| 13:23:59 | efried | aspiers: ack. jfyi, there's gonna be a mktme spec coming down the pipe here pretty soon. You'll be pleased to see all the "make this generic" prep will be justified. | |
| 13:24:13 | aspiers | efried: oh, interesting! who's working on that? | |
| 13:24:17 | aspiers | you? | |
| 13:24:37 | efried | nah, I'll be reviewing it closely, but it'll be coming from someone else, not completely sure who. | |
| 13:24:53 | efried | I think it'll be in U though. | |
| 13:25:18 | aspiers | gotcha | |
| 13:26:21 | aspiers | efried: I'll only add to you to reviews from bbobrov which I think are ready. No point you burning time reviewing stuff where I have already identified some deficiencies which need addressing. | |
| 13:26:41 | efried | aspiers: I've been keeping my eye on those with the same philosophy :) | |
| 13:27:56 | aspiers | efried: Having said that, I did write a couple of comments addressed to you | |
| 13:28:18 | aspiers | but they can wait until the -1s are dealt with | |
| 13:29:19 | kashyap | efried: When you get time, the other day you said you might have some comments: https://review.opendev.org/#/c/661574/ ["Document mitigation for Intel MDS security flaws"] | |
| 13:29:53 | kashyap | efried: I'll wait to respin it until I get your comments; FWIW, it has a +2 from Alex | |
| 13:30:38 | efried | kashyap: ack, I'll look at that rn... | |
| 13:48:02 | lyarwood | johnthetubaguy: https://review.opendev.org/#/c/652800/ - thanks for the review, as this is already failing in the gate could you remove your +W so I could add a bug link in? | |
| 13:49:02 | efried | kashyap: passive aggressive +0 with lots of notes https://review.opendev.org/#/c/661574 | |
| 13:49:44 | efried | lyarwood: You don't need johnthetubaguy to remove his +W; it'll clear if you just submit a new patch set. | |
| 13:49:57 | efried | ...I'm pretty sure? Now you got me doubting. | |
| 13:50:30 | lyarwood | efried: ah cool thanks, I'll try that now | |
| 14:04:57 | kashyap | efried: Heh, just looking. On the "SMT vulnerable" thing, yes, that didn't sit well with me either. Allow me to expand: | |
| 14:05:20 | efried | kashyap: Expand in the document | |
| 14:05:26 | efried | I believe you | |
| 14:05:32 | kashyap | efried: You will see "SMT vulnerable" when you have not disabled hyperthreading in the BIOS | |
| 14:05:40 | kashyap | (Yes, will certainly expand there, too.) | |
| 14:05:58 | efried | Yeah, so I don't know that that means. All I know is I see 'vulnerable' and that worries me. | |
| 14:06:17 | efried | but I don't know if "Mitigation: ... vulnerable" means I've mitigated the vulnerability | |
| 14:06:19 | efried | or what | |
| 14:06:36 | efried | maybe it'll be obvious to anybody who's actually qualified to be following this guide | |
| 14:06:40 | efried | if so, tell me that. | |
| 14:07:07 | efried | or maybe it would be clear by reading, from top to bottom, the link you referenced | |
| 14:07:17 | efried | which I did not do as part of my review :) | |
| 14:07:24 | efried | if so, you can tell me that too. | |
| 14:09:08 | cdent | fg | |
| 14:09:11 | cdent | oops ww | |
| 14:09:48 | cdent | I temporarily have more screen real estate than I can see in one glance | |
| 14:15:12 | efried | that sounds like a problem I want to have | |
| 14:18:08 | edleafe | Heh, I type into the wrong window at least once a day. Fortuantely, I don't type my passwords too often | |
| 14:23:09 | kashyap | edleafe: Hope you use a password manager :D | |
| 14:24:41 | edleafe | kashyap: Been using LastPass for 8 years now, and love it. But some VMs I use require passwords instead of SSH keys. LastPass doesn't work at a terminal :) | |
| 14:25:40 | kashyap | Nod; whatever works (and is not buggy). | |
| 14:26:03 | kashyap | efried: Whoops, missed the rest of the chat here. I'll respond to them all on the review. | |
| 14:39:12 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Add regression recreate test for bug 1830747 https://review.opendev.org/662774 | |
| 14:39:13 | openstack | bug 1830747 in OpenStack Compute (nova) "Error 500 trying to migrate an instance after wrong request_spec" [High,In progress] https://launchpad.net/bugs/1830747 - Assigned to Matt Riedemann (mriedem) | |
| 14:51:27 | efried | kashyap, aspiers, mdbooth: Who's good with libvirt's use of lvm/cinder for swap devices? | |
| 14:51:41 | efried | ...or has the background to understand that fairly quickly | |
| 14:51:57 | mdbooth | efried: Me, probably | |
| 14:52:17 | mdbooth | *cinder* for swap? | |
| 14:52:19 | efried | mdbooth: Cool. Ima throw you on a review if you don't mind. | |
| 14:52:26 | efried | I'm not sure, really. | |
| 14:52:28 | efried | https://review.opendev.org/#/c/618621/ | |
| 14:52:41 | efried | It's pretty raw at this point - I get the impression the contributor is very new to coding. | |
| 14:52:56 | efried | but perhaps you can provide guidance as to whether the fix is sane, going in the right direction. | |
| 14:53:17 | kashyap | efried: mdbooth indeed | |
| 14:54:23 | efried | mdbooth: Note that this came from ML thread http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006807.html which I just responded to - but my response was only in the context of "here's how to get tests to pass". | |
| 14:54:35 | efried | I don't have the background to know whether the fix is any good. | |
| 14:55:05 | mdbooth | Ack. I have a short meeting in a couple of minutes, but I'll try to look at this properly within the next few hours. | |
| 14:55:11 | efried | thank you mdbooth | |
| 15:15:22 | openstackgerrit | Merged openstack/nova master: Add extra logging to request filters https://review.opendev.org/657629 | |
| 15:25:43 | mriedem | just fyi, dfw nodes are having issues this morning so you'll be rechecking if you hit one of those nodes | |
| 15:26:11 | mriedem | error message of "('Connection broken: IncompleteRead(0 bytes read)', IncompleteRead(0 bytes read))" | |
| 15:31:40 | gibi | mriedem: left a comment in https://bugs.launchpad.net/nova/+bug/1829479 | |
| 15:31:41 | openstack | Launchpad bug 1829479 in OpenStack Compute (nova) "The allocation table has residual records when instance is evacuated and the source physical node is removed" [Undecided,Incomplete] | |
| 15:38:27 | openstackgerrit | Merged openstack/nova master: Ensure that metadata proxy raises correct exception https://review.opendev.org/661480 | |
| 15:47:03 | efried | thanks mriedem, seen a few of those :( | |
| 15:47:11 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix no propagation of nova context request_id https://review.opendev.org/662715 | |
| 15:55:23 | efried | mriedem: Loading an instance from the db, setting expected_attrs makes it load those fields right away; if I don't do that, I can still access the fields, but they'll get loaded later, which is another db hit and therefore slow. Do I have this right? | |
| 15:56:36 | mriedem | correct | |
| 15:56:50 | efried | Cool, so https://review.opendev.org/#/c/662683/ is sane | |
| 15:56:50 | mriedem | e.g. https://review.opendev.org/#/c/657021/ | |
| 15:57:15 | mriedem | i reported that bug but it should be hopefully what i said to do in the bug | |
| 15:58:12 | efried | oh | |