Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-03
10:13:50 cdent because it would be duplicating the contents of the files, almost verbatim
10:14:06 aspiers well, the contents of the commit messages maybe
10:14:09 cdent if there were something other than a list of strings in the package, it would make sense
10:14:24 aspiers no great loss I guess
10:14:39 aspiers although it doesn't sound like much additional effort either
10:14:46 cdent the reason we encourage the comments linking to docs is so that the point of the trait is obvious, with the trait
10:15:05 cdent I'd really rather not add that much redundancy
10:15:23 aspiers I'm thinking from the distro packager and operator perspective, not for developers
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

Earlier   Later