Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-03
10:39:49 aspiers Hah, I'm totally obsessive too
10:40:30 cdent there's also a twisted sense of "must keep the dream (a vague thing) alive"
10:40:32 aspiers If opendev Gerrit had an activity infogram like GitHub does, you'd see me doing plenty at weekends. but then I take it easier in the week to balance things out
10:40:50 aspiers As in, "OpenStack is dying, gotta save it" ?
10:40:58 aspiers I think it's a long way from that
10:41:24 cdent something a bit like that, but not quite the same. not quite openstack is dying, but some of the economic models associated with it
10:41:45 aspiers yeah maybe
10:42:04 cdent for me, personally, a lot of it was the goal of getting placement extracted
10:42:16 aspiers Well that's a nice thing to be proud of, looking back
10:42:17 cdent since it was supposed to be extracted from the start, it was, to me, 3 years late
10:42:37 cdent so each year it was more late, was more uphill that needed to be travelled
10:42:47 aspiers know the feeling
11:00:08 kashyap cdent: Do write it up. (Yikes, indeed! 60-80 hours)
11:00:42 cdent kashyap: the blog post written above is a start, but there will probably be some followups if the feedback loop is sufficiently dense
11:01:38 kashyap I also try not to do more than 40 (focused) hours, effectively they translate to 38 1/2 (official).
11:02:16 cdent I think the "focused" thing is a bit of a trap. Presumably we should charge our employers for the time it takes to get warmed up, and the time it cost for them to interrupt us?
11:02:27 kashyap Fewer hours, restful sleep, comfortably paced days, realistic deadlines, time to consider --- these are things I value for a long, sustaible stint in this industry.
11:02:59 kashyap cdent: Yeah, I know what you mean; when we "turn off", our minds are still on the problem often times. There's a lot of "residue" that needs cleaned up
11:03:44 kashyap I feel, that's one reason why most people those who do intense knowledge work don't feel restored after a weekend.
11:05:40 cdent or to go the other way why some people who do intense knowledge work prefer not to come down off the intensity: it takes too much effort to get back up there
11:08:16 kashyap cdent: Ha: "I've limited my sphere of concern" -- sounds like Stoicism :-)
11:08:48 aspiers kashyap: I've done the same
11:09:00 cdent kashyap: yes it's exactly that
11:09:08 cdent accept the things I cannot change, and such
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.)

Earlier   Later