- Wednesday, October 25, 2017

release-team@conference.openafs.org

Wednesday, October 25, 2017< ^ >

Room Configuration

Room Occupants

GMT+0
[12:54:00] meffie joins the room
[14:31:03] meffie leaves the room
[14:39:59] meffie joins the room
[14:40:55] <kadukoafs@gmail.com/barnowl371B93C9> It looks like my meeting that is normally at T-0:30 got rescheduled to
T, so I'll probably be absent.
I started coding up an rx/event patch but progress was slow and I got
bogged down in some other projects.
[15:01:38] <meffie> ok, andrew tells me he's started reviewing the rxgk patchsets that are currently in gerrit.
[15:03:38] <mvita> hello
[15:03:45] <meffie> hello mvita
[15:04:14] <mvita> a coding question:
[15:04:16] <mvita> 865     tt = (struct ubik_trans *)malloc(sizeof(struct ubik_trans));
866     memset(tt, 0, sizeof(struct ubik_trans));
[15:04:42] <mvita> some would say it's okay to ignore NULL from the malloc because if you're gonna fail, get a core.
[15:05:05] <mvita> so this serves as a defacto assert
[15:06:09] <mvita> but I don't know what the OpenAFS tradition is - should this malloc be checked or not?
[15:06:57] <mvita> (this is userspace code in ubik servers)
[15:07:16] <meffie> first, most of the malloc/memsets have been replaced with calloc()
[15:07:50] <meffie> normally, we do/should check the results of malloc/calloc
[15:08:38] <mvita> are there any circumstances where it's valid to not check?
[15:09:17] wiesand joins the room
[15:09:33] <mvita> I don't like the "get a core" argument because an out of memory core will probably be useless unless you can find a leak that caused the problem.
[15:09:54] <wiesand> my apologies for being late
[15:10:21] <meffie> i dont think so. either assert or propagate ENOMEM to the caller.
[15:10:33] <mvita> aye, so we are in agreement.
[15:10:42] <mvita> tx
[15:11:07] <meffie> good afternoon wiesand
[15:12:55] <wiesand> any chance we could get reviews on https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:openafs-stable-1_8_x ?
[15:13:25] <mvita> looking
[15:13:51] <mvita> oh, those - sorry Stephan, I meant to get to those last week
[15:13:53] <mvita> doing it now
[15:14:10] <wiesand> Merging those should hopefully make the 1.8.x daily builds suceed again, and I think we'll need those for 1.6.21.2...
[15:14:21] <mvita> right
[15:16:23] <wiesand> 12740 should be ok to include as well
[15:16:49] <meffie> sorry, i missed those backports as well.
[15:18:49] <wiesand> Is 12742 for 1.6.21.2 or 1.6.22?
[15:20:56] <wiesand> And: any new insights regarding EL7.4 kernels / getcwd?
[15:21:11] <mvita> no, sorry, still slogging away on that.
[15:21:34] <meffie> 12742 could be for 1.6.21.2. any feedback from the tester?
[15:21:58] <mvita> as you said, it could be shakeloose exposing the same old problems, but I need to prove that
[15:22:20] <mvita> I also have some ideas on mitigation if that's it, but they are just ideas until I can duplicate the issue and find root cause
[15:22:22] <wiesand> So far I've seen no evidence that the existing reports are *not* simply due to re-including "shake harder".
[15:22:59] <mvita> I continue to work on getcwd
[15:23:18] <wiesand> My "standard reproducer" doesn't trigger the problem.
[15:23:23] <wiesand> Mark: thanks.
[15:23:47] <mvita> btw, could you refresh me on your "standard reproducer" ?
[15:23:53] <meffie> oh, can you share your 'standard reproducer', we'd like to including it in openafs-robotest
[15:24:06] <mvita> ^ this
[15:24:06] <meffie> like to include it
[15:24:47] <wiesand> git clone the openafs repo; sleep 120; git log
[15:24:57] <wiesand> not quite cheap
[15:24:57] <meffie> ok, thanks!
[15:25:58] <wiesand> I'm afraid I don't have more items for today.
[15:26:07] <kadukoafs@gmail.com/barnowl371B93C9> I'm just arrived
[15:26:13] <kadukoafs@gmail.com/barnowl371B93C9> but I don't think I have any other items
[15:26:32] <meffie> just wanted to check if there is anyone that can test the high sierra dmg, stephan?
[15:27:32] <wiesand> No luck yet. Folks interested in AFS on macOS are refraining from updating to high sierra
[15:27:46] <meffie> ah! yes, that seems common...
[15:28:02] <meffie> we are testing with a vm.
[15:29:03] <wiesand> I guess "bind mount" is well on its way? ;-)
[15:29:22] <kadukoafs@gmail.com/barnowl371B93C9> Back when my main machine was a mac, I didn't even install AFS at all
on the bare metal -- I didn't want to risk destabilizing the kernel,
as it was hosting a giant VM farm.  I did have an OS X VM for testing
stuff, though.
[15:29:23] <meffie> not yet, mark is just trying to repro the current getcwd problem.
[15:30:14] <mvita> yes, I'm focused on tactical stuff at the present - the bind mount solution is long term
[15:30:28] <wiesand> like BER ;-)
[15:30:31] <mvita> unless I come up empty on tactical solutions, that is
[15:31:00] <meffie> ok, thanks mvita.
[15:32:32] <wiesand> Mark: We're not worried at all about the differences in configure test results between EL7.3 and EL7.4 kernels, right?
[15:32:38] <meffie> kadukoafs@gmail.com/barnowl371B93C9: i pushed a patch set for converting xstat et al to pthreads. but it looks like i need to squash some of the intermediate changes in that series
[15:32:40] <mvita> right
[15:33:53] <kadukoafs@gmail.com/barnowl371B93C9> meffie: I saw, thanks!
Well, that or you need to link them to -lpthread on not-Solaris ;)
[15:33:56] <meffie> (btw kaduk, jabber thinks there are 2 of you here)
[15:34:01] <wiesand> Mike: the quest for an LWP free OpenAFS?
[15:34:08] <kadukoafs@gmail.com/barnowl371B93C9> Indeed, I get two copies of everything.
[15:34:24] <kadukoafs@gmail.com/barnowl371B93C9> wiesand: exactly
[15:34:39] <kadukoafs@gmail.com/barnowl371B93C9> Should we auction off the rights to 'git rm src/lwp'? ;)
[15:34:56] <meffie> yep. we are almost there on master. just upclient stuff left i think?
[15:35:42] <wiesand> Ben: Nice idea. Maybe the revenue could revive the foundation…
[15:35:43] <kadukoafs@gmail.com/barnowl371B93C9> Hmm, were we going to remove upclient/upserver entirely on master?
[15:36:08] <mvita> still in use at some sites
[15:36:16] <meffie> well, i keep finding more and more sites using it, so i think we better keep it around.
[15:36:31] <kadukoafs@gmail.com/barnowl371B93C9> Sigh.
[15:36:36] <mvita> sorry
[15:36:52] <kadukoafs@gmail.com/barnowl371B93C9> "But it's on https://wiki.openafs.org/archive/OpenAFS18Notes/ as to be
removed from master post-branch, with no question mark"
[15:36:52] <meffie> there's lots of other stuff in the tree not in use we could kill :)
[15:37:03] <mvita> afsmonitor
[15:37:05] <mvita> scout
[15:37:07] <mvita> uss
[15:37:26] <wiesand> hey wait
[15:37:29] <mvita> mcas ( I think Ben already got that one)
[15:37:31] <kadukoafs@gmail.com/barnowl371B93C9> Please feel free to add to the wiki page
[15:37:49] <kadukoafs@gmail.com/barnowl371B93C9> I only took mcas off 1.8; it's still on master
[15:37:59] <kadukoafs@gmail.com/barnowl371B93C9> but arguably should go away there, too
[15:38:12] <wiesand> someone remind me what "mcas" was after all?
[15:38:26] <meffie> lockless locking
[15:38:29] <mvita> lock free goodness, I think
[15:38:47] <mvita> but it was never exploited except in some tests
[15:38:48] <kadukoafs@gmail.com/barnowl371B93C9> "what they said"
[15:39:07] <wiesand> ah, yes, rings a bell - thanks
[15:39:39] <mvita> kaserver
[15:39:53] <wiesand> kill it. now.
[15:39:53] <mvita> (just kidding)
[15:40:12] <mvita> sadly also still in use
[15:40:16] <wiesand> (no kidding)
[15:40:28] <wiesand> (no sympathy)
[15:40:31] <meffie> no, i'm thing of the java stuff, and all the old "install" stuff that is not used and broken, etc.
[15:40:42] <mvita> YES - that netscape junk
[15:41:24] <kadukoafs@gmail.com/barnowl371B93C9> It's not entirely clear what of kaserver and kauth and friends is
required as a condition of using the AFS name.
[15:41:27] <wiesand> Getting 1.8 into shape should have higher priority IMHO
[15:41:45] <kadukoafs@gmail.com/barnowl371B93C9> wiesand: I agree.
[15:41:50] <meffie> yes
[15:42:12] <meffie> we are just looking ahead a bit.
[15:42:20] <wiesand> Ben: Good point. So, break it. Now. :-)
[15:42:20] <kadukoafs@gmail.com/barnowl371B93C9> And I don't have much interest in paying a lawyer to figure out
whether it's safe to deorbit kaserver.
On the other hand, who would care enough to sue.
[15:42:43] <mvita> IBM
[15:42:45] <wiesand> Inadvertently, of course.
[15:43:31] <wiesand> (now, just kidding)
[15:43:43] <mvita> yes, the need to continue kaserver support is why I originally said "just kidding"
[15:44:10] <mvita> we probably need to keep the source even if _no_ site is using it
[15:44:24] <wiesand> :-(
[15:44:51] <mvita> but not building it by default is a good compromise
[15:45:22] <kadukoafs@gmail.com/barnowl371B93C9> Well, that we do already.
[15:45:28] <mvita> right
[15:45:29] <meffie> yes, and we've already changed the packaging to put it in a separate rpm.
[15:45:41] <meffie> which is not made by default.
[15:45:56] <mvita> but… maybe kaserver will make a comeback once it is pthreaded!
[15:46:11] <meffie> i think it is pthreaded now, no?
[15:46:17] <mvita> 8-|
[15:46:26] <kadukoafs@gmail.com/barnowl371B93C9> Hmm, do we need to change the buildbot config to --enable-kauth to
keep it compiling?
[15:46:38] <wiesand> I'll not say that bit rot will do the rest…
[15:46:46] <wiesand> No....
[15:47:20] <kadukoafs@gmail.com/barnowl371B93C9> It doesn't look like kauth is pthreaded; it still uses
Makefile.lwptool
[15:47:29] <meffie> oh, no it's still LWP. drat.
[15:47:57] <wiesand> Where's the problem? :->
[15:48:03] <meffie> nm kaserver | grep -c pthread
0
nm kaserver | grep -c LWP
22
[15:48:12] <mvita> we have drifted off topic
[15:48:15] <kadukoafs@gmail.com/barnowl371B93C9> Er, hmm, but Makefile.lwptool is supposed to build for both, so
that's not exactly the right argument to be making.
[15:48:27] <kadukoafs@gmail.com/barnowl371B93C9> I think the meeting is basically done and we're just socializing
[15:48:40] <wiesand> So, remove LWP, don't touch kaserver, solved.
[15:48:40] <mvita> oh, carry on then!
[15:49:50] <wiesand> I agree that we're finished for today.
[15:49:50] <meffie> or just mv LWP and kserver to an "old" directory.
[15:50:08] <mvita> > wiesand> hey wait      which component was this for, Stephan?
[15:50:14] <meffie> "src/historic-relics"
[15:50:20] <mvita> are you still using something we mentioned?
[15:50:32] <wiesand> Mark: scout, afsmonitor - great tools
[15:50:45] <mvita> ah, okay, I was not aware
[15:50:47] <meffie> i know scout is still in use.
[15:50:51] <mvita> sorry
[15:51:20] <wiesand> Well I use them rarely, but it's good to know they exist.
[15:51:24] <meffie> and it can cause issues with the servers if enough people are running it :)
[15:51:34] <wiesand> Oh...
[15:51:41] <mvita> scout is lwp
[15:51:47] <meffie> not in gerrit :)
[15:52:22] <meffie> issues as in, there is some performance overhead.
[15:52:57] <meffie> and since it's not authenticated, it's possible to have non-admins running it.
[15:53:58] <meffie> but, yes, i think we should keep them if possible.
[15:54:45] <meffie> ok, thanks for the chat. it was good to get this out of my system. :)
[15:54:59] <meffie> have a good day all.
[15:55:12] <mvita> later
[15:55:30] <wiesand> Thanks a lot. CU.
[15:55:30] meffie leaves the room
[15:55:31] wiesand leaves the room
[15:56:21] <kadukoafs@gmail.com/barnowl371B93C9> Thanks, everyone!
[18:11:29] meffie joins the room
[20:49:01] meffie leaves the room
[20:49:46] meffie joins the room
[21:25:00] meffie leaves the room