- Friday, May 31, 2019

release-team@conference.openafs.org

Friday, May 31, 2019< ^ >

Room Configuration

Room Occupants

GMT+0
[11:59:35] mbarbosa joins the room
[12:01:11] meffie joins the room
[12:52:26] meffie leaves the room
[12:52:26] meffie joins the room
[12:56:34] meffie leaves the room
[12:56:45] meffie joins the room
[12:59:48] wiesand joins the room
[13:01:13] <wiesand> Good morning
[13:04:32] <meffie> good morning
[13:04:44] <meffie> good afternoon.
[13:05:18] <wiesand> "something got in the way" right after last week's meeting, thus I have no news
[13:05:44] <meffie> ok
[13:05:45] <wiesand> I should be able to spend part of Sunday on openafs
[13:06:12] <meffie> ok, I can work on the NEWS today for 1.8.x if that helps?
[13:06:12] <wiesand> So there is still some hope we'll have some news in time for the workshop
[13:06:25] <wiesand> At least I'll try hard to make that happen
[13:06:33] <meffie> thank you
[13:06:53] <wiesand> I'm starting to worry about Ben
[13:07:13] <meffie> yes
[13:07:41] <meffie> i assume we should change the time for this weekly meeting. later would be good for me too.
[13:08:48] <wiesand> probably
[13:08:56] <wiesand> 3h?
[13:09:16] <meffie> (fyi, mark v is out of the office today)
[13:09:26] <wiesand> ok, thanks
[13:10:25] <wiesand> +3h would still kind of work for me, but I'd prefer +2 - what's your preference?
[13:11:13] <meffie> +2 would work well for me.
[13:11:42] <meffie> so that would be 11:00am EST, right?
[13:11:58] <wiesand> and I think it would be the same time for Ben as in his previous location?
[13:12:11] <meffie> yes
[13:12:42] <meffie> i think so.
[13:14:01] <wiesand> yes, 11am EST, 8am Pacific, 5pm for me
[13:14:25] <wiesand> if I got the math right
[13:14:57] <wiesand> any news from your side?
[13:16:17] <meffie> andrew has pushed some performance improvements to gerrit (master). he has some graphs he will be sharing at the workshop to show how he can fill a 10g pipe on with these
[13:16:39] <meffie> they are changes in rx to improve fileserver performance
[13:16:49] <wiesand> "sendmmsg" topic?
[13:17:06] <meffie> yes, and recvmmsg
[13:17:07] <wiesand> and "recvmsg"
[13:17:51] <wiesand> conforming to the AFS3 protocol?
[13:18:03] <meffie> yes, just fixes inside of rx
[13:18:50] <wiesand> and no tradeoffs?
[13:20:14] <meffie> well, they have to be reviewed and such. they are being used in a lab environment and started to be tested in hpc environments.
[13:21:00] <meffie> there are a series of changes, he is trying to be care to not introduce bugs.
[13:21:07] <meffie> careful
[13:22:11] <wiesand> yes, he's doing it right (as always), splitting the while change into reasonably sized patch sets
[13:22:25] <meffie> the recvmmsg takes advantage of the newer recvmmsg calls that did not exist when rx was invented, for example.
[13:22:26] <wiesand> (from what I've seen in the last minutes)
[13:23:00] <meffie> so some of this is really just using modern apis when available.
[13:23:28] <wiesand> sounds very promising
[13:23:36] <meffie> yes
[13:25:30] <wiesand> I'd like to try these, but I'm not going to promise - I have enough urgent homework to do
[13:25:37] <meffie> other news, a buildbot has been added for fedora 29, and it is working now as of yesterday.
[13:25:47] <meffie> and a fedora 30 is on the way.
[13:25:54] <wiesand> But Ill put the stacks on the wishlist for future stable releases
[13:26:08] <wiesand> very good, thanks!
[13:26:34] <meffie> they have been made by Derek Atkins
[13:27:31] <wiesand> thanks to him too
[13:28:09] <wiesand> the builders are pretty fast currently too
[13:28:12] <meffie> i will keep an eye on the fedora29 buildbot, and if it does ok for a bit, will add it to the pool of gerrit builders.
[13:28:45] <wiesand> good thing that our code base growth is not keeping pace with technology development ;-)
[13:29:14] <meffie> cheyenne wills will be helping me make some improvements to the buildbot master, probably after the workshop.
[13:29:28] <meffie> heh
[13:29:54] <meffie> yes, the bottleneck is "configure" :)
[13:30:40] <wiesand> right
[13:31:09] <meffie> also, this week, i've added "debian/ubuntu" support to the ansible-openafs roles
[13:31:30] <wiesand> if we could teach buildbot not to build the kernel module if the change doesn;t touch it, that would be quite a boost in those cases…
[13:31:56] <meffie> that is an interesting suggestion!
[13:32:34] <wiesand> not quite trivial to implement I'm afraid though
[13:33:04] <meffie> it would be trivial if we used git submodules, i'm guessing.
[13:33:12] <meffie> but we cant do that now.
[13:33:53] <meffie> still, it's the configure that takes most of the time :)
[13:34:38] <wiesand> in my builds, ~90% of that time is spent on kernel feature tests
[13:35:05] <meffie> yes
[13:35:13] <wiesand> which aren't executed when configuring —without-kernel-module
[13:35:32] <meffie> those can be cached, which can help, but then you have to manage the configure cache.
[13:37:00] <meffie> it would be trivial to create a set of "user space only" builders that always build with --without-kernel-module.
[13:37:42] <meffie> i'm not sure if that helps you ?
[13:39:25] <wiesand> not so much, since changes I work on are supposed to succeed building, with failures being the exception
[13:39:42] <meffie> ok.
[13:40:19] <wiesand> but it may help developers pushing their new changes
[13:40:42] <meffie> hmm, ok.
[13:41:40] <wiesand> anyway, as I said it's currently not bad at all
[13:42:18] <meffie> ok. we plan on working on "robustness" next (not speed).
[13:42:49] <wiesand> sounds good
[13:42:51] <meffie> i.e. dealing with one gerrit buildbot going offline gumming up the works.
[13:43:25] <wiesand> I agree that's more of a problem than performance right now
[13:43:25] <meffie> it should be possible to address that.
[13:43:37] <meffie> ok, thank!
[13:43:41] <meffie> thanks.
[13:44:46] <wiesand> have 2 builders for each setup, verify +1 if one succeeds?
[13:44:55] <wiesand> expensive…
[13:46:13] <meffie> the idea (from the buildbot devs) is to define low-priority "virtual build workers" that can respond when the real build worker is offline.
[13:46:46] <meffie> so the build set can complete for a given scheduled build
[13:47:23] <meffie> normally, the "normal" solution is to have more hardware.
[13:48:07] <meffie> which is expensive, but then if one goes down, you have others that can fill in.
[13:48:09] <wiesand> nice idea, but it won't catch the cases where workers are online but wedged in some way (git checkout fails due to full filesystem…)
[13:48:52] <meffie> yes, good point, but we can do some sort of time out for those.
[13:49:07] <meffie> it's the "offline" ones that are the real problem i think.
[13:50:01] <wiesand> I have limited statistics her, but I'm not sure that's right
[13:50:08] <meffie> also, we should have a way to replay a gerrit. just to retry building it.
[13:50:22] <wiesand> yes, I'm missing that
[13:50:47] <meffie> maybe that should be done first.
[13:51:03] <wiesand> completely up to you ;-)
[13:51:14] <meffie> a sort of manual override :)
[13:51:59] <wiesand> maybe if the "virtual workers" kicked in whenever a build fails on a single worker only?
[13:53:20] <meffie> ok, i'll talk to cheyenne. he is going to help me so i'm not the only one that knows about the buildbot :)
[13:54:01] <wiesand> ok
[13:54:12] <meffie> that's all i have today.
[13:54:35] <wiesand> Fine. Let's adjourn then. Thanks a lot Mike!
[13:54:57] wiesand leaves the room
[13:54:58] <meffie> ok, thanks wiesand, have a good weekend!
[14:11:48] meffie leaves the room
[16:18:45] kaduk@jabber.openafs.org/barnowl joins the room
[21:48:01] mbarbosa leaves the room