Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-03
10:15:31 aspiers the former two shouldn't have to read code
10:15:50 cdent I think reno makes sense for the services, but for libraries that are merely symbols the distros should just do the normal thing: read the commit histroy
10:16:19 aspiers yeah, commit history is probably good enough
10:17:01 cdent I'm not trying to be a jerk about it or anything, it's just that there's limited capacity and things like that level of white glove service is why some people choose disros
10:18:19 aspiers sure
10:18:43 aspiers you're succeeding, not just trying :)
10:19:12 cdent some other day I'll successfully be a jerk
10:19:38 aspiers I'm sure; I can promise you it's pretty easy - for me anyway ;-)
10:20:10 cdent I've been having quite a lot of thoughts (mostly vague) lately on how to economize upstream development
10:23:01 cdent mostly with regard to making gaps more visible
10:26:40 aspiers oh?
10:26:54 aspiers what kinds of gaps?
10:30:39 cdent aspiers: some of the concepts are sort of in this https://anticdent.org/openstack-denver-summit-reflection.html but basically: making it more obvious where we don't have enough resources by simply choosing to not do things
10:33:36 aspiers cdent: yikes! 60-80 hours?
10:33:59 cdent at least
10:34:02 aspiers I do 30 (well, theoretically - probably do more due to same self-imposed perverse sense of loyalty)
10:35:54 aspiers all good thoughts there
10:36:02 cdent Is that 30 of upstream work plus some amount of time of other work, or 30 is your work week, or something else?
10:36:28 aspiers work week
10:37:03 cdent I'm very happy to hear that you're able to do that, there really needs to be more of that.
10:38:02 aspiers I don't understand why any developer outside a startup would need to work long weeks
10:38:40 cdent interesting. you're the only one I speak to regularly who has said they do not
10:39:03 aspiers 40 I can understand, but why more?
10:39:19 aspiers I mean, if you get paid for the overtime then fair enough, otherwise it seems crazy
10:39:31 cdent obsessiveness
10:39:37 aspiers If I'm gonna hack in my spare time, it'll be on other FOSS
10:39:47 cdent the aforementioned perverse loyalty
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.

Earlier   Later