Home
release-team@conference.openafs.org
Wednesday, November 8, 2017< ^ >
Room Configuration
Room Occupants

GMT+0
[00:39:58] mvita joins the room
[00:44:39] mvita leaves the room
[13:30:54] meffie joins the room
[14:27:13] mvita joins the room
[16:00:30] <meffie> good day.
[16:00:38] <mvita> hello
[16:01:33] <kadukoafs@gmail.com/barnowl0AF0C398> Greetings
[16:02:11] <kadukoafs@gmail.com/barnowl0AF0C398> Mark, I made a few tweaks to the rx-event patch to fix some nits that
Mike found; do you want to have a look (and hopefully re-+1)?
[16:02:19] wiesand joins the room
[16:02:30] <wiesand> Hello
[16:02:30] <mvita> I have been looking at it for most of the morning.
[16:03:04] <kadukoafs@gmail.com/barnowl0AF0C398> Ah, good that you saw it already.
(Sorry that it is taking so long?)
[16:03:26] <wiesand> Mark, any news on your investigations into EL7.4 kernels and/or the getcwd() issues?
[16:03:48] <mvita> I think I understand the drop submount thing
[16:04:07] <mvita> I thought I found the getcwd root cause yesterday but now I'm not so sure.
[16:04:17] <mvita> so, no, still working on both.
[16:04:27] <wiesand> That's something, good., thanks a lot.
[16:05:07] <wiesand> They released a 4.14-rc8, so the next release isn't super-urgent IMO.
[16:05:29] <kadukoafs@gmail.com/barnowl0AF0C398> Yes, a big thanks for that progress.
[16:05:36] <mvita> yes, I saw that.
[16:06:46] <wiesand> But non-4.14 changes for 1.6 are piling up, so maybe we change our mind and go for a 1.6.22 with 4.14 support plus the simpler / very low risk fixes? W/o a pre1?
[16:07:22] <wiesand> Thoughts?
[16:08:01] <mvita> <I try to think but nothing happens>
[16:08:10] <meffie> hmm, i was hoping the ubik fixes would be in a 1.6.22 release
[16:08:32] <meffie> as it is now, the first write on the vlserver causes you to lose quorum.
[16:08:36] <wiesand> Well, we can still issue a 1.6.23 one
[16:08:41] <kadukoafs@gmail.com/barnowl0AF0C398> piling up in gerrit, or piling up on the branch?
[16:08:54] <wiesand> in gerrit
[16:09:20] <wiesand> I don't start merging before we seem reasonably close to the (pre)release
[16:09:30] <meffie> also, the solaris deadlock panic fix should go in a release at some point
[16:09:51] <mvita> well, the solaris deadlock is stalled on me
[16:09:52] <kadukoafs@gmail.com/barnowl0AF0C398> > I don't start merging before we seem reasonably close to the (pre)release
*nods*
[16:10:02] <meffie> for those unfortunate souls on solaris
[16:10:11] <mvita> hey
[16:10:43] <wiesand> are the ubik fixes completely merged onto master and 1.8 yet anyway?
[16:10:55] <meffie> i believe so
[16:11:41] <meffie> and they are running in prod in some places that patch the tree so they can keep using openafs :)
[16:12:22] <wiesand> But for a release with those included I still require a reasonably long public testing phase.
[16:12:42] <wiesand> So it's not the next release, whatever that will be called.
[16:12:53] <meffie> yeah, good point. we would not want to short cut a pre release for those changes.
[16:13:14] <wiesand> OTOH, simple stuff like ...
[16:13:46] <meffie> ok, thanks. i can put a list of gerrits numbers in an email on release-team for a future release.
[16:14:03] <wiesand> 12740, 12724, 12643 keep piling up (and the latter already has a merge conflict with one fo the 4.14 changes)
[16:14:22] <kadukoafs@gmail.com/barnowl0AF0C398> I suppose I could be persuaded that a 1.6.22 without pre1 is
reasonable.
[16:14:51] <wiesand> I'd like to get those out of the way, but they don't belong into a 1.6.21.2 release IMHO.
[16:15:02] <kadukoafs@gmail.com/barnowl0AF0C398> Though it may be worth taking a closer look at the changes once you
send that list.
[16:15:18] <kadukoafs@gmail.com/barnowl0AF0C398> I agree about not belonging in a 1.6.21.2, yes
[16:15:46] <wiesand> But also stuff like the lastest gtfx change should be released timely.
[16:15:57] <kadukoafs@gmail.com/barnowl0AF0C398> But yeah, I see people running into some of those on IRC with some
frequency.
[16:17:32] <wiesand> I have a project to finish before the weekend, and I'm behind schedule… but I can hopefully propose a list of non-4.14 changes for a no-prerelease 1.6.22 before next week's meeting.
[16:17:49] <meffie> sounds great. thanks wiesand.
[16:18:33] <kadukoafs@gmail.com/barnowl0AF0C398> ==meffie
[16:19:33] <meffie> i agree, if we can get some of these build and logging fixes out, it would be nice.
[16:19:56] <wiesand> Obviously, having getcwd/EL7.4 fixed in whatever will be the next 1.6 release would be even better. Let's see what we have next week.
[16:20:19] <wiesand> On to 1.8pre3/master?
[16:20:34] <meffie> and it would be nice for the people that contributed the fixes to see their contributions getting into a release in a timely fashion!
[16:21:35] <wiesand> Sure...
[16:22:29] <kadukoafs@gmail.com/barnowl0AF0C398> I don't know who all was still in the room when I was telling Mike
that I was hoping to get 1.8.0pre3 out today with the rx-event fix.
So thank you all for reviewing that one!
[16:23:31] <kadukoafs@gmail.com/barnowl0AF0C398> I plan to remove the -DRX_REFCOUNT_CHECK for the cherry-pick to 1.8.x
[16:23:40] <kadukoafs@gmail.com/barnowl0AF0C398> Does anyone have comments about that?
[16:24:03] <meffie> i've been running it with some extra tracing to watch the refcounts. seems to be working as expected.
[16:24:21] <kadukoafs@gmail.com/barnowl0AF0C398> yay
[16:24:51] <mvita> no comment on removing -DRX_REFCOUNT_CHECK
[16:24:53] <meffie> i think it's ok the remove the -DRX_REFCOUNT_CHECK, but maybe leave a comment about how to enable it for testing.
[16:25:09] <mvita> ^ agreed about the comment
[16:25:17] <kadukoafs@gmail.com/barnowl0AF0C398> Sounds good.
[16:25:58] <meffie> the commit message was excellent. thank you.
[16:26:35] <kadukoafs@gmail.com/barnowl0AF0C398> It started out life as a note to myself so I could keep track of how
things worked.  And, well, that seems like somsething worth sharing.
[16:27:10] <meffie> heh. that's great.
[16:27:52] <meffie> i'm going to have to start doing that, just remove the cuss words before pushing.
[16:28:00] <mvita> HA
[16:28:13] <kadukoafs@gmail.com/barnowl0AF0C398> Ha!
[16:28:43] <wiesand> I don't care
[16:29:18] <wiesand> they can actually help judge...
[16:29:37] <meffie> yes, i suppose.
[16:31:39] <meffie> ok, should we let wiesand get back to his project?
[16:32:06] <kadukoafs@gmail.com/barnowl0AF0C398> I guess for 1.8 there's also the gtx thing
[16:32:24] <meffie> the build issue?
[16:32:25] <kadukoafs@gmail.com/barnowl0AF0C398> Sorry for the delay, I was rereading the event commit message as part
of my pre-merge review.
[16:32:38] <kadukoafs@gmail.com/barnowl0AF0C398> Yeah, the libcurses-linked-against-libtinfo thing
[16:33:03] <kadukoafs@gmail.com/barnowl0AF0C398> I probably would be okay merging it with just my own review, but if
anyone has a moment, more review is always appreciated.
[16:33:10] <kadukoafs@gmail.com/barnowl0AF0C398> But that's probably all I have for 1.8.
[16:33:54] <kadukoafs@gmail.com/barnowl0AF0C398> And while we can mention that Andrew made some comments on the rxgk
patchset and I pushed some updates to address them, there's not really
much of an action item for us to discuss there.
[16:34:00] <mvita> I should be able to finish my rxevent review shortly, then get back to the RH7.4 spaghetti farm.
[16:34:03] <kadukoafs@gmail.com/barnowl0AF0C398> So, yes, I think wiesand can safely get back to his project.
[16:34:04] <meffie> ok, i saw it, but did not review.
[16:34:32] <kadukoafs@gmail.com/barnowl0AF0C398> Sure
[16:35:02] <mvita> can we talk about RH stuff in general for a bit?
[16:35:06] <wiesand> great :-/ (if I enjouyed working on it it would be finsihed...)
[16:35:19] <wiesand> (my project)
[16:35:27] <wiesand> Mark: sure
[16:35:33] <kadukoafs@gmail.com/barnowl0AF0C398> Sure, we can talk about RH stuff -- "when are we going to remove it
all?" :-P
[16:35:35] <mvita> I'm starting to realize that RH/CentOS in particular raise some extra barriers for us.
[16:36:11] <wiesand> Ouch
[16:36:12] <mvita> Is there anything we could have done (say in the build farm) to get earlier notice of these RH 7.4 issues?
[16:37:02] <wiesand> Become a Red Hat partner, and get access to the non-public betas this way.
[16:37:07] <mvita> ah.
[16:37:52] <mvita> I will have to check - Sine Nomine may already be a RH partner (for other parts of our business)
[16:38:35] <mvita> How closely do Fedora releases foreshadow future RH releases?
[16:39:20] <kadukoafs@gmail.com/barnowl0AF0C398> Supposedly there is a policy that anything going into RH has to go
through fedora first, but I am just remembering what one of the
kerberos folk said on IRC and may well be misremembering
[16:39:58] <wiesand> Loosely speaking, I think they branch ~18 months before a major EL GA release
[16:40:13] <meffie> i believe that was the intent. not sure if that happens in practice (fedora -> rhel)
[16:41:01] <wiesand> It is. Every ~4 years. Nowadays rather every 5+ years.
[16:41:41] <wiesand> And then Fedora's objective is rapid progess, and EL's is stabilization.
[16:42:57] <wiesand> That gap has become too wide.
[16:43:33] <wiesand> EL has to fix issues no longer present in current Fedora at all.
[16:43:55] <wiesand> (so they were never fixed there)
[16:44:08] <mvita> it sounds like having Fedora builder(s) would not provide much help for early identification of RH issues.
[16:44:39] <wiesand> IMHO: no
[16:44:55] <mvita> and we already do have a bunch of Fedora builders - I always forget about that.
[16:45:09] <mvita> they are relatively new, are they not?
[16:45:27] <meffie> new and old. and we are getting a newer one soon.
[16:45:44] <wiesand> But they just build, right?
[16:46:03] <meffie> yes
[16:46:05] <mvita> yes, just build.
[16:46:20] <mvita> so seeing some tests there would be interesting.
[16:47:11] <wiesand> Like running the client with -stat 2000 and executing the getcwd reproducer...
[16:47:29] <wiesand> NB I guess bind-mount is almost finished? ;-)
[16:47:49] <meffie> i can stand up a kvm virtual machine to do ${tests} on ${os}
[16:48:36] <mvita> bind-mount - I've looked at it more closely this week.  No it's not finished ;-p
[16:48:54] <wiesand> oh, surprise
[16:49:10] <mvita> did I leave the impression it would be done this week?
[16:49:40] <mvita> I remember saying "months" away.
[16:49:42] <wiesand> no
[16:51:53] <meffie> btw, the linux nightly builders do run the basic test suite (the RF based one).
[16:52:00] <wiesand> but still thanks for taking a closer look
[16:52:41] <meffie> so, I can add more client tests, and add more nightly builders for ${os} to run them if you need.
[16:52:57] <mvita> okay
[16:53:17] <mvita> I hope to have some client tests soon (for RF, that is)
[16:53:34] <wiesand> enlighten me what RF is?
[16:53:41] <mvita> robot framework
[16:53:44] <meffie> robotframework
[16:53:52] <wiesand> thanks
[16:54:02] <mvita> Mike built an OpenAFS framework over it
[16:54:09] <mvita> we use it in-house for regression testing
[16:54:29] <mvita> and it is also in the openafs.org Linux daily and rc builders
[16:54:53] <meffie> i've pushed the tests and libs to gitbhub.
[16:54:58] <meffie> er. github
[16:55:11] <mvita> so anyone can use it, or contribute to it
[16:55:53] <meffie> https://github.com/openafs-contrib/openafs-robotest
[16:58:08] <wiesand> But back to Mark's remark… why do you think RH is raising the hurdles for us?
[16:58:40] <mvita> 1) no visibility of individual commits
[16:59:21] <wiesand> Well that's an attempt to protect against fierce competition
[16:59:21] <mvita> 2) willingness to add commits that were never in upstream Linux
[16:59:49] <wiesand> Yes, that was worrying me too
[16:59:56] <kadukoafs@gmail.com/barnowl0AF0C398> I do think it would be very useful to get more client/server testing
into robotest.
[17:00:30] <wiesand> But the case of (2) I found didn't affect openafs at all, as you pointed out
[17:01:07] <mvita> well, it turns out one of their custom changes does have a bearing on the submount issue.
[17:01:23] <kadukoafs@gmail.com/barnowl0AF0C398> (BTW, https://github.com/freebsd/freebsd/tree/master/contrib/pjdfstest
is some freebsd-originating filesystem stress testing suite, though I
never got very far running it, and some of the things it tests are not
things we expect to pass.)
[17:01:31] <meffie> > I do think it would be very useful to get more client/server testing into robotest.
please send ideas for tests cases and i'll try to implement them.
[17:02:37] <meffie> also, keep in mind the RF tests are not meant to be stress tests, but functional tests. stress tests will be a horse of a different color.
[17:02:54] <kadukoafs@gmail.com/barnowl0AF0C398> Okay.
[17:03:28] <mvita> back to the existing Fedora builders for a moment, then I'm done….
[17:03:42] <mvita> I see they are not triggered like the other builders.
[17:04:06] <mvita> Where can I find information about when/why a given builder runs?
[17:04:24] <meffie> https://buildbot.openafs.org/builders/fedora26-x86_64-builder
[17:04:34] <meffie> "The SingleBranchScheduler scheduler named 'gerrit_scheduler' triggered this build"
[17:04:50] <mvita> yes - where can I see the schedulers?
[17:05:11] <kadukoafs@gmail.com/barnowl0AF0C398> I think we put the fedora builders in as nightly to see how they would
do, and then failed to actually follow up and make them triggered like
we had planned to.
[17:05:32] <meffie> the schedulers are part of the configuration.
[17:05:37] <kadukoafs@gmail.com/barnowl0AF0C398> https://github.com/openafs-contrib/afsbotcfg/blob/master/master.cfg#L100
[17:06:20] <mvita> ah, okay.  I was hoping to see that information represented somewhere in the web interface.
[17:06:25] <meffie> yes, thanks. it's in github. the schedulers are not visible in the web interface
[17:06:42] <meffie> you can see the build reason in the web interface.
[17:09:01] <mvita> Okay, thank you everyone.
[17:09:06] <meffie> > I think we put the fedora builders in as nightly to see how they would
do, and then failed to actually follow up and make them triggered like
we had planned to.
i've promoted them to gerrit builders
[17:09:41] <kadukoafs@gmail.com/barnowl0AF0C398> yay, thanks
[17:09:51] <meffie> per conversions with you and Derek.
[17:10:24] <wiesand> As long as they're reliable, the more the marrier.
[17:10:43] <kadukoafs@gmail.com/barnowl0AF0C398> sounds good
[17:10:44] <meffie> yes, and they are the fastest builders we have!
[17:11:11] <wiesand> It's the slowest one that matters.
[17:11:38] <wiesand> But it's not so bad right now.
[17:12:11] <wiesand> Anyway, yes, thanks.
[17:12:23] <wiesand> Looks like we're finished for today?
[17:12:32] <kadukoafs@gmail.com/barnowl0AF0C398> I think so
[17:12:33] <mvita> I think so.
[17:12:38] <meffie> thanks everyone.
[17:12:41] <kadukoafs@gmail.com/barnowl0AF0C398> Thanks everyone!
[17:12:51] <wiesand> Let's adjourn then. Thanks a lot everyone!
[17:13:21] wiesand leaves the room
[18:27:51] <kadukoafs@gmail.com/barnowl0AF0C398> mvita: do you want me to refrain from pushing the 'submit' button on
12756 for now?
[18:34:33] <mvita> yes, please, I'm just getting back to it now
[18:34:49] <kadukoafs@gmail.com/barnowl0AF0C398> Okay, happy to give you the time you need.
[20:16:59] meffie leaves the room
[20:25:58] <mvita> kaduk:  updated
[20:26:06] <kadukoafs@gmail.com/barnowl0AF0C398> mvita: thanks!
[21:01:58] meffie joins the room
[22:01:48] meffie leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!