Home
release-team@conference.openafs.org
Friday, May 11, 2018< ^ >
Room Configuration
Room Occupants

GMT+0
[11:52:14] Marcio Barbosa joins the room
[12:51:39] meffie joins the room
[12:52:39] <meffie> good morning. network connectivity may be spotty for me today, i'm currently at pycon2018.
[12:53:00] <kaduk@jabber.openafs.org/barnowl> Howdy.  How is pycon treating you?
[12:53:27] <meffie> it is rather huge. i didnt realize it was so large.
[12:54:42] <kaduk@jabber.openafs.org/barnowl> Ah.
[12:54:51] <kaduk@jabber.openafs.org/barnowl> I guess Python is pretty popular, or something :)
[12:55:16] <kaduk@jabber.openafs.org/barnowl> Want to do a quick review on https://gerrit.openafs.org/#/c/13060/ ?
[12:57:50] <meffie> oh, did i miss a vrequest in the old commit :(
[12:57:57] wiesand joins the room
[13:00:15] <kaduk@jabber.openafs.org/barnowl> I mean, I did, too :-/
[13:00:16] Marcio Barbosa leaves the room
[13:00:33] <wiesand> Hello
[13:01:04] <wiesand> I have some good & bad news - which one first?
[13:01:05] <kaduk@jabber.openafs.org/barnowl> greetings
[13:01:14] <meffie> good afternoon.
[13:01:32] <meffie> bad news
[13:01:58] <kaduk@jabber.openafs.org/barnowl> oh?
[13:01:59] <wiesand> 1) I haven't gotten anything done this week. No pre1 today
[13:02:05] mvita joins the room
[13:02:10] <wiesand> 2) I have only 30 minutes today
[13:02:13] <meffie> oh, that's not so bad.
[13:02:25] <mvita> present
[13:02:26] <wiesand> Both for the same reason (private matter with high priority)
[13:02:33] Marcio Barbosa joins the room
[13:03:09] <wiesand> The good one: it seems we're fine on the EL 6.10 kernel
[13:03:17] <meffie> yay
[13:03:21] <kaduk@jabber.openafs.org/barnowl> That's pretty good news :)
[13:03:33] <mvita> huzzah!
[13:04:25] <wiesand> Configure results differ in a single item: the new kernel has set_nlink
[13:05:22] <wiesand> And yes, it is in fs.h. Single use in osi_vnodeops.c, and it all makes sense to me.
[13:05:36] <wiesand> I also have it running on a test system.
[13:06:05] <wiesand> So that's the one thing I did get done.
[13:06:15] <mvita> thank you!
[13:06:34] <meffie> thank you wiesand.
[13:06:38] <kaduk@jabber.openafs.org/barnowl> Yes, thank you!
[13:07:28] <wiesand> I see 13062 is new. Already earmarked it for 1.6.23
[13:08:03] <wiesand> And there's some more churn happening on master/1.8 right now. Which ones are .23 candidates?
[13:08:09] <kaduk@jabber.openafs.org/barnowl> Yeah, a kind of embarassing typo for someone, though IIRC from the
history it was part of a sweeping change
[13:08:54] <kaduk@jabber.openafs.org/barnowl> I'm not sure there's much other than the rpm packaging (if we even
took the prerequisites for it on 1.6)
[13:09:16] <kaduk@jabber.openafs.org/barnowl> Oh, I guess there's jaltman's rx serial number/abort thing, 12931 and
12932
[13:10:01] <kaduk@jabber.openafs.org/barnowl> And I forget how hard you said it was to pull back the sweeping
changes to autoconf/configure
[13:10:07] <meffie> i think we should target getdslot-eintr for 1.6.23 too. those fix panics people talked about related to systemd
[13:10:36] <kaduk@jabber.openafs.org/barnowl> Fair enough.  (I was looking at the log on master and hadn't pulled up
a gerrit listing yet)
[13:10:48] <wiesand> Ben: The biggest part is already merged thanks to Mike's backport.
[13:10:59] <wiesand> Additional ones shouldn't be too hard now
[13:11:07] <kaduk@jabber.openafs.org/barnowl> I guess Marcio's OS X stuff could probably go in a .23
[13:11:34] <wiesand> I must have missed that...
[13:11:51] <kaduk@jabber.openafs.org/barnowl> The vice partition name checks might be nontrivial for 1.6, since we
maybe don't have strlcpy available there.
[13:11:53] <meffie> i think the new macos stuff is for 1.8.x,
[13:12:07] <kaduk@jabber.openafs.org/barnowl> 13063/4/5 for Marcio's stuff, it just showed up yesterday and is not
merged yet
[13:13:07] <wiesand> ah, thanks. I'll keep an eye on those
[13:13:59] <kaduk@jabber.openafs.org/barnowl> The 'public-api' topic on master should not be relevant for 1.6
[13:14:20] <wiesand> no, I agree
[13:14:22] <Marcio Barbosa> > i think the new macos stuff is for 1.8.x,
yes
[13:14:32] <meffie> sorry i didnt have a chance to review the public-api topic yet
[13:14:33] <wiesand> except if it helps reduce skew and is low risk…
[13:15:58] <meffie> maybe we cant make those types of api cahnges in the old stable branch
[13:16:05] <kaduk@jabber.openafs.org/barnowl> > sorry i didnt have a chance to review the public-api topic yet
things happen.
Probably more changes are desired there anyway.  I guess while we're
all here, though, I can ask how people feel about exposing the RPC
functions to get the index into the DB of a given entry, or to fetch a
block from a specific index (which are administrator-only operations,
of course).
[13:16:26] <kaduk@jabber.openafs.org/barnowl> I mean, the libtool stuff is just not in the old stable branch at all.
[13:16:56] <wiesand> sure
[13:18:09] <meffie> hmm, not sure.
[13:18:43] <wiesand> I meant the libtool stuff
[13:19:35] <wiesand> I don't have an opinion on public-api (yet)
[13:20:08] <mvita> PR_WhereIsIt
[13:20:12] <mvita> PR_DumpEntry
[13:21:18] <meffie> i suspose if you consider the "index" to be an id, that might be ok.
[13:21:35] <mvita> no, it's the offset into the prdb
[13:21:51] <mvita> pretty raw interface
[13:22:05] <mvita> I don't think it should be public, no
[13:22:18] <mvita> I don't think it should exist, but that ship has sailed
[13:22:20] <kaduk@jabber.openafs.org/barnowl> (Though I don't mean to sidetrack from 1.6 if Stephan still has more
things to talk about before his time runs out)
[13:22:21] <meffie> understood, but that is exposing the physical layout
[13:22:33] <wiesand> (no :)
[13:24:04] <meffie> i think exposing a numeric id (that is meant to be a quick index, in the general sense) would work
[13:24:29] <meffie> most dbs have that concept
[13:25:07] <meffie> the id would not necessarily be the offset in the file
[13:25:34] <meffie> my 2 cents/ first thoughts
[13:26:19] <mvita> the numeric id of the user or group is already the input into PR_WhereIsIt
[13:26:44] <mvita> I'm not sure I understand what you are proposing.
[13:27:07] <kaduk@jabber.openafs.org/barnowl> I think the proposal is that "the API documentation will call this an
opaque index and not refer to the structure on disk at all".
[13:27:35] <mvita> ah
[13:27:35] <kaduk@jabber.openafs.org/barnowl> But I don't think we could actually get away with trying to limit it
like that, since the implementation detail has already escaped into
the wild.
[13:27:37] <meffie> yes, that makes sense to me
[13:27:55] <mvita> an opaque index that can be fed back to PR_DumpEntry
[13:28:02] <meffie> yes
[13:28:06] <mvita> eww
[13:28:20] <meffie> no, that makes sense
[13:28:27] <mvita> defining it as opaque is good
[13:28:34] <meffie> yes
[13:28:50] <mvita> but… there's no reason to expose this interface to the DB
[13:28:53] <kaduk@jabber.openafs.org/barnowl> (We also don't have any API documentation where we could put such a
statement, IIRC.)
[13:29:05] <mvita> we already have direct fetch of an entry by user id
[13:29:23] <wiesand> Sorry, I have to run now (little house for sale in the neighbourhood - could be the one…)
[13:29:33] <kaduk@jabber.openafs.org/barnowl> go go go!
[13:29:41] <mvita> run, run like the wind!
[13:29:42] <kaduk@jabber.openafs.org/barnowl> And thanks, as always
[13:30:06] wiesand leaves the room
[13:30:27] <mvita> (PR_ListEntry, of course)
[13:34:05] <meffie> are we ready for the next topic?
[13:34:33] <kaduk@jabber.openafs.org/barnowl> I guess so, and I guess that would be 1.8 status/updates
[13:34:42] <kaduk@jabber.openafs.org/barnowl> We had two failure reports this week :(
[13:34:53] <meffie> ah. ok.
[13:35:16] <meffie> one was with cachebypass?
[13:35:21] <kaduk@jabber.openafs.org/barnowl> Yup
[13:35:30] <meffie> (enabled that is)
[13:35:33] <meffie> ok, sorry.
[13:35:42] <meffie> what was the 2nd?
[13:35:46] <kaduk@jabber.openafs.org/barnowl> I'm not sure if the user saw my link to the patch or not, though.  I
suppose I could do another reply noting that disabling cache bypass
would be a workaround
[13:35:50] <mvita> ah, wait, I see why PR_ListEntry is not the logical equivalent of PR_WhereIsIt + PR_DumpEntry
[13:36:02] <mvita> PR_ListEntry returns a prcheckentry
[13:36:02] <meffie> (correct)
[13:36:14] <mvita> PR_DumpEntry returns a prdebugentry
[13:36:22] <mvita> many more fields
[13:36:27] <kaduk@jabber.openafs.org/barnowl> The 2nd was that the Debian package we (MIT) have for python-afs
doesn't build on Ubuntu Buster
[13:36:30] <mvita> not retrievable any other way
[13:36:31] <meffie> (yes, it is a lower level abstraction)
[13:36:48] <kaduk@jabber.openafs.org/barnowl> (which is what led to the public-api topic)
[13:36:58] <meffie> i'm at pycon, i'll tell them to fix python.
[13:37:28] <kaduk@jabber.openafs.org/barnowl> I have to remember what the upstream is for this python-afs; it may be
someone MIT-ish anyway.
[13:38:12] <kaduk@jabber.openafs.org/barnowl> The immediate failure mode is that it was trying to use the static
libraries, which now depend on roken.
[13:38:17] <mvita> I withdraw my objections to making those two public
[13:38:41] <kaduk@jabber.openafs.org/barnowl> (Hmm, do we even provide pkgconf files for them?)
[13:39:14] <kaduk@jabber.openafs.org/barnowl> Anyway, with static libraries normally the consuming application is
responsible for doing dependency tracking in some way, so I suggested
that Anders try with the shared libraries; it was only then that he
(non-)exported symbols were discovered.
[13:39:54] <kaduk@jabber.openafs.org/barnowl> It's probably best to just comment on 13056 regarding the
DumpEntry/etc. functions
[13:39:54] Marcio Barbosa leaves the room
[13:40:40] <kaduk@jabber.openafs.org/barnowl> Oh, I guess before the linking errors were the compile errors with the
missing afs/opr.h and opr/lock.h headers.
[13:41:30] <kaduk@jabber.openafs.org/barnowl> For some reason I had thought that maybe we did not want to make all
of OPR part of the public API, but I couldn't actually find any
evidence of that in my email archive or the git logs.
[13:41:56] <kaduk@jabber.openafs.org/barnowl> But I did want to get another opinion or three before actually
publishing afs/opr.h in the public API.
[13:42:04] Marcio Barbosa joins the room
[13:43:32] <meffie> ok, in general, there is great room for improvement for openafs programable interfaces :)
[13:43:39] <kaduk@jabber.openafs.org/barnowl> :)
[13:47:16] <meffie> sorry they had the build failures. i suppose that is why we had pre-releases tho.
[13:47:45] <kaduk@jabber.openafs.org/barnowl> Yeah, we did all we could reasonably expect to do.
[13:48:16] <kaduk@jabber.openafs.org/barnowl> And our stuff works fine standalone so far as we can tell (modulo
cachebypass), so we seem to be doing okay.
[13:48:54] <meffie> whew. more info the hepix talk :)
[13:49:17] <mvita> What's the cachebypass issue?
[13:49:57] <kaduk@jabber.openafs.org/barnowl> We used osi_Free instead of afs_DestroyReq and it panics because the
allocation is from a different bucket
[13:50:32] <kaduk@jabber.openafs.org/barnowl> (https://rt.central.org/rt/Ticket/Display.html?id=134533)
[13:52:15] <mvita> thanks, I hadn't heard about this
[13:52:28] <meffie> it's new
[13:52:48] <meffie> i think?
[13:52:53] <kaduk@jabber.openafs.org/barnowl> Date:    Tue, 8 May 2018 16:20:14 -0400 (EDT)
[13:55:39] <kaduk@jabber.openafs.org/barnowl> But anyway, back to the public-api topic for a bit -- I assume there
are other symbols that we should be exporting (e.g., ubik_VL_*);
someone should take a look and see if there's anything obvious.
On linux, I think you can use something like `nm libafsrpc.so.2.0.0`
and look for symbols with lowercase 't' in the second column as things
in the text but not exported (which would be 'T').
[13:56:53] <mvita> looking
[13:57:08] <kaduk@jabber.openafs.org/barnowl> (Probably shouldn't be during the meeting)
[13:57:11] <meffie> i remember there was some symbols i needed for the collectd module i had started.
[13:57:21] <meffie> there were some
[13:57:28] <kaduk@jabber.openafs.org/barnowl> *nods*
[13:58:56] <meffie> if we get them for the 1.8.x series, i can publish a useable collectd module and try to get it upstream in collectd.
[13:59:32] <kaduk@jabber.openafs.org/barnowl> nifty!
[14:00:29] <meffie> yeah, that would be nifty. would be easier to get data into stuff like graphite.
[14:00:40] <mvita> I didn't find any unexported ubik_VL_*
[14:01:45] <kaduk@jabber.openafs.org/barnowl> Oh, hmm, maybe those aren't present in either afsrpc or afsauthent; I
didn't think too hard when coming up with the example.
[14:01:58] <kaduk@jabber.openafs.org/barnowl> or maybe they're just in afsauthent and not afsrpc
[14:04:16] <kaduk@jabber.openafs.org/barnowl> And perhaps some of the xdr_foo support routines are needed in order
for some of the RPC functions to actually be usable.
[14:05:29] <kaduk@jabber.openafs.org/barnowl> Anyway, this topic seems about covered as far as meeting time goes.
[14:05:35] <meffie> ok
[14:05:55] <kaduk@jabber.openafs.org/barnowl> As people hopefully saw in mail, I would like to do a 1.8.1 pretty soon
to get these fixes out.  Are there other things we'd like to get into
1.8.1?
[14:06:19] <meffie> how about the dvhints / fast path stuff?
[14:06:56] <meffie> that would make openafs useable for some situations where it is not today
[14:07:07] <meffie> such as building out of afs
[14:07:07] <kaduk@jabber.openafs.org/barnowl> I didn't get to fully digest the latest comments on it, but I was not
convinced that it was actually safe, the last time I looked.
[14:08:15] <meffie> yeah is it not suitable for 1.6.x, but it has been in use for some time now
[14:08:32] <meffie> at one site that is.
[14:08:42] <kaduk@jabber.openafs.org/barnowl> Well, I will try to take another look at it, I guess.
[14:10:10] <meffie> oh, was there a solaris build issue we wanted for 1.8.1? andrews fix for the broken libtool on solaris?
[14:10:27] <kaduk@jabber.openafs.org/barnowl> I want to say that got pulled up already, but let's check...
[14:10:39] <meffie> maybe that's on master only?
[14:10:54] <kaduk@jabber.openafs.org/barnowl> https://gerrit.openafs.org/12949 is on 1.8
[14:11:56] <meffie> not that on, that doest actually fix the error
[14:11:56] Marcio Barbosa leaves the room
[14:12:46] Marcio Barbosa joins the room
[14:13:11] <kaduk@jabber.openafs.org/barnowl> I don't think "Suppress statement not reached warnings under Solaris
Studio" is on 1.8 yet, though
[14:13:30] <meffie> 12945 fixes the build error on solaris
[14:14:08] <kaduk@jabber.openafs.org/barnowl> Is there a pullup to 1.8 in gerrit?
[14:14:09] <meffie> (unless one patches the libtool with a fix for the current version)
[14:14:27] <meffie> i dont see a pull up for 12945
[14:15:57] <kaduk@jabber.openafs.org/barnowl> Please Make It So, then :)
[14:16:50] <meffie> ok, i'll push a pull up tonight
[14:17:03] <kaduk@jabber.openafs.org/barnowl> Thanks
[14:17:32] <kaduk@jabber.openafs.org/barnowl> Any other topics?  (master?)
[14:17:43] <meffie> i cant think of anything else for 1.8.x
[14:19:17] <meffie> other topics i have: 1. buildbot, 2. hepix2018
[14:19:52] <meffie> 1. buildbot. i think i have fixed the linux-rc daily builders
[14:20:02] <kaduk@jabber.openafs.org/barnowl> yay
[14:20:16] <mvita> Thank you Mike.
[14:20:29] <meffie> just required jumping to the new version of ubuntu, 18.04 LTS
[14:21:03] <meffie> i need to document how these builders work, i'll put that on the openafs wiki later.
[14:21:39] <meffie> i did not looking automatically starting the buildbot master on reboot. i dont think i have sudo access to do so anyway.
[14:22:09] <meffie> i did not look at.
[14:23:16] <kaduk@jabber.openafs.org/barnowl> Yeah, the machine doesn't go down very often so it may not be worth
the bother.
[14:23:42] <meffie> the new linux-rc builders do not have --enable-checking, because we dont build without warnings on new versions of gcc
[14:24:17] <meffie> i made a new regular nightly ubuntu 18 builder with checking on. we should fix the warnings :)
[14:24:18] <kaduk@jabber.openafs.org/barnowl> We should probably tweak our cflags to be able to do that
[14:24:47] <meffie> or suppress the ones we cant easily fix?
[14:25:31] <kaduk@jabber.openafs.org/barnowl> right, that
[14:25:32] <meffie> any way, that's my buildbot report. sorry it took so long
[14:25:55] <meffie> so long to get the builders working, that is.
[14:26:19] <kaduk@jabber.openafs.org/barnowl> We can still be happy that they are working now
[14:26:33] <meffie> ok, glass is half full.
[14:26:44] <mvita> heh
[14:26:52] <meffie> 2. hepix.
[14:27:00] <mvita> glass is 2x bigger than it needs to be
[14:28:30] <meffie> the openafs release team report is tuesday afternoon or wed morning. i need to write a draft for people here to review. sorry i've not done that yet.
[14:28:30] Marcio Barbosa leaves the room
[14:29:47] <meffie> i'm at pycon today, and will be at my daughters graduation on sat, so it may not be ready for review until sunday :(
[14:30:19] <meffie> the timeslot is only 20 minutes (max)
[14:30:36] Marcio Barbosa joins the room
[14:32:35] <meffie> i plan on covering the releases we have been making, issues that have been fixed, that sort of thing.
[14:33:05] <meffie> i'm open to any suggestions :)
[14:33:18] <mvita> There should be cake.
[14:34:07] <meffie> true
[14:34:56] <mvita> you could make a call for volunteers (reviewers, contributors, etc)
[14:35:31] <mvita> testers
[14:35:48] <meffie> ok
[14:35:56] <mvita> Definitely mention the build farm and how awesome its maintainers are.
[14:36:26] <meffie> there will be a foundation talk also, with appeals
[14:36:34] <mvita> Oh, good.
[14:36:41] <mvita> I was wondering.
[14:37:30] <meffie> anyway, motion to adjourn?
[14:37:47] <mvita> okay
[14:38:08] <mvita> Mike, I can look at your draft any time, just call/text my cell
[14:38:18] <meffie> ok, thanks!
[14:39:20] <meffie> kaduk@jabber.openafs.org/barnowl: ?
[14:39:37] <kaduk@jabber.openafs.org/barnowl> I'm happy to look at the draft too, though have weaker guarantees
about availability.
[14:39:41] <kaduk@jabber.openafs.org/barnowl> But yes, I think we can adjourn.
[14:40:01] <meffie> thank you, have a good weekend everyone.
[14:40:10] <mvita> you too
[14:40:17] meffie leaves the room
[14:40:34] <kaduk@jabber.openafs.org/barnowl> Yes, thanks all
[15:24:02] mvita leaves the room
[15:45:33] Marcio Barbosa leaves the room
[15:47:37] Marcio Barbosa joins the room
[15:53:57] mvita joins the room
[16:40:02] Marcio Barbosa leaves the room
[16:42:08] Marcio Barbosa joins the room
[17:51:08] Marcio Barbosa leaves the room
[17:53:19] Marcio Barbosa joins the room
[18:13:16] mvita leaves the room
[18:13:49] mvita joins the room
[19:04:34] Marcio Barbosa leaves the room
[19:07:40] Marcio Barbosa joins the room
[20:11:38] mvita leaves the room
[20:12:38] mvita joins the room
[21:40:56] mvita leaves the room
[21:48:50] Marcio Barbosa leaves the room