| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-03 | |||
| 11:09:21 | kashyap | [Look up "Epictetus and sphere of choice"] | |
| 11:09:23 | aspiers | I've weaned myself away from being the bottleneck for various downstream stuff | |
| 11:09:37 | kashyap | aspiers: Excellent; effective > productive. | |
| 11:09:46 | aspiers | People were always like "oh, it's an HA problem, ask aspiers" | |
| 11:10:22 | aspiers | but I'm managing to get away from that | |
| 11:11:33 | kashyap | aspiers: Yeah, I hear you. Spreading expertise is always a challenge, and is a deliberate choice | |
| 11:12:08 | aspiers | I made some training slides, gave some training sessions, recorded them, made the videos available, documented as much as I could | |
| 11:12:27 | aspiers | then just point people at that | |
| 11:12:55 | kashyap | Yeah, you did more than you can. | |
| 11:13:20 | johnthetubaguy | some of the most productive folks I know are always very good at FAQ management like that, I wish I was better at it! | |
| 11:14:00 | kashyap | johnthetubaguy: Yes! "Document _anything_ that moves" is the motto I try to drill down to whoever is willing to listen :D | |
| 11:14:17 | kashyap | (Triply important when everyone is remote) | |
| 11:15:32 | kashyap | cdent: On another point from your post: "it probably also means limiting required attendance to events like PTGs and summits" | |
| 11:16:39 | kashyap | I've said it before, I'll say it again: it is absolute baloney for people to _insist_ to join 2 PTGs. (Let alone the maddening times when people were having *4* in-person meet-ups at a time, running around like head-less chickens.) | |
| 11:17:40 | cdent | I don't mind them existing. I mind them being exclusive | |
| 11:17:44 | kashyap | cdent: IOW, I'm with your view there; and people should *learn* to write better, and engage in written discussion. Of course, _do_ meet in person, by all means; it's vital. But limit it to once (and make it optional). People have various reasons. | |
| 11:17:52 | cdent | If, for example, red hat sent all openstack engineers to the ptg, then cool | |
| 11:17:58 | cdent | but if only special ones can go, that's bs | |
| 11:19:39 | cdent | kashyap: yes on the writing | |
| 11:19:51 | cdent | but you and I have covered that many times | |
| 11:20:12 | kashyap | (Nod) | |
| 11:20:28 | kashyap | cdent: More generally, do get your rest back, and feel restored. There lies more power to you. | |
| 11:20:41 | cdent | yes, thank you. | |
| 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. | |