Home
release-team@conference.openafs.org
Friday, September 4, 2020< ^ >
kaduk@jabber.openafs.org/barnowl has set the subject to: openafs release team
Room Configuration
Room Occupants

GMT+0
[11:21:06] meffie leaves the room
[12:05:36] mbarbosa joins the room
[13:04:15] mbarbosa leaves the room
[13:04:51] mbarbosa joins the room
[13:30:52] meffie joins the room
[14:51:36] mbarbosa leaves the room
[14:51:57] mbarbosa joins the room
[15:46:47] yadayada joins the room
[15:48:03] mbarbosa joins the room
[15:48:26] mbarbosa leaves the room
[15:49:06] kaduk@jabber.openafs.org/barnowl joins the room
[15:50:57] cwills joins the room
[16:00:58] wiesand joins the room
[16:01:08] <meffie> good afternoon.
[16:01:17] <wiesand> Hi
[16:01:17] <yadayada> Hello
[16:01:18] <kaduk@jabber.openafs.org/barnowl> greetings
[16:02:14] <wiesand> Not that much from my side today.
[16:02:53] <wiesand> I noticed Revert "vos: take RO volume offline during convertROtoRW"
[16:03:04] <meffie> yes
[16:03:17] <wiesand> (settled hint to Ben: getting that off the table next would be most helpful)
[16:03:26] <kaduk@jabber.openafs.org/barnowl> Apparently we did it wrong the first time, yeah
[16:03:49] <kaduk@jabber.openafs.org/barnowl> (probably that was "subtle hint"?)
Well, you want not just the revert but also the proper fix, right?
[16:04:00] <meffie> sorry about that. i did not occur to me it was possible to do in the volserver.
[16:04:16] <wiesand> The revert is more important.
[16:04:21] <kaduk@jabber.openafs.org/barnowl> It didn't occur to me, either!
[16:04:22] <cwills> good day everyone
[16:04:29] <kaduk@jabber.openafs.org/barnowl> Hi Cheyenne
[16:04:55] <meffie> (i'm so used to working around stuff in volprocs ;)
[16:05:46] <wiesand> Re 14314, I'm clueless why it's required, but it certainly won't do any harm.
[16:06:03] <meffie> (s/volprocs/vsprocs/)
[16:06:52] <kaduk@jabber.openafs.org/barnowl> I was surprised by 14314 at first, too, but came to see the need
[16:07:10] <wiesand> Among the rest of https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:openafs-stable-1_8_x , there are quite a few where another +1 would make me a bit more comfortable merging them.
[16:07:20] <meffie> 14314?
[16:08:15] <meffie> it is to avoid errors when installing with DKMS on new centos machines. that's where i hit the problem.
[16:08:56] <meffie> because 'make' is not installed by default.
[16:08:59] <yadayada> 14314 looks valid as for dkms to work, "make" is needed. So it is good to make it as requirement. However to build we will need kernel-header and kernel-devel too. Hope that reuiqrement is also met ?
[16:09:08] <wiesand> (Especially since Andrew tends to punish me for merging w/o sufficient review, like in the convertROtoRW case ;-)
[16:09:40] <meffie> the kernel header and devel are tricky because they are versioned.
[16:10:15] <meffie> so it seems not a best practice to put those in the spec depends?
[16:10:20] <wiesand> The requires(post) or even a plain requires ought to be sufficient.
[16:11:55] <wiesand> The kernel (headers) stuff is terrible, the main reason being the fedora folks being stubborn fighting off "external" kernel modules. But hey, "make"?!
[16:12:30] <meffie> we use make in configure, so that is needed as a prereq.
[16:13:31] <meffie> (and flex is needed too)
[16:13:34] <kaduk@jabber.openafs.org/barnowl> (using make *in* configure is a bit weird, which is what had tripped
me up at first.  Normally make comes after configure.)
[16:13:47] <wiesand> Ah, that makes sense.
[16:13:48] <meffie> agreed!
[16:14:12] <cwills> I believe that the make is needed to test kernel modules
[16:14:21] <wiesand> "configure; make; make install" - it comes right from the spine
[16:14:24] <cwills> (test for "features" in kernel modules)
[16:14:45] <meffie> yes, but it is weird to use make *in* configure. it's an openafs-ism.
[16:15:23] <meffie> anyway. :)
[16:15:31] <wiesand> Thanks, this removes my last worries (which were pretty minor anyway) regarding that change.
[16:16:42] <cwills> So .. quick report I was able to do a build (and quick smoke test) on a fedora-33 nightly with 1.8.x (and master)
[16:16:57] <wiesand> So, please review review review (and please merge that revert commit). But that's what I have for today.
[16:17:12] <wiesand> F33 is using Linux 5.8 now?
[16:17:19] <cwills> biggest issue was fedora-33 has dropped des as a key type
[16:17:47] <cwills> yes 5.8, btrfs as the default filesystem and the change in kerberos just mentioned
[16:17:55] <kaduk@jabber.openafs.org/barnowl> Yeah, we didn't get a huge amount of use out of the -insecure_des
optino in debian, either.
[16:18:21] <wiesand> What's required to cope?
[16:18:59] <cwills> Well.. for the testing I just needed to configure kerberos with a supported key type
[16:19:26] <cwills> I used: master_key_type to aes256-sha2
[16:19:43] <kaduk@jabber.openafs.org/barnowl> IIRC the fileserver has a hardcoded list of filesystems it will run
on, and btrfs is not on that list
[16:19:57] <wiesand> Spell it out to dummies like me?
[16:19:57] <kaduk@jabber.openafs.org/barnowl> Ooh, getting all fancy with the new enctypes, I see
[16:20:33] <kaduk@jabber.openafs.org/barnowl> It sounds like cwills has a local test setup script that uses
single-DES keys, and had to change that to using modern kerberos keys
[16:21:39] <cwills> s/cwills has a/cwills uses a meffie provided/ :)
[16:22:15] <kaduk@jabber.openafs.org/barnowl> Hmm, but VAttachPartitions() has a billion different per-OS versions,
and I don't see such checks in the linux one, so maybe that's a red
herring
[16:22:31] <kaduk@jabber.openafs.org/barnowl> Oh, so I get to give meffie a hard time about single-DES, then? ;)
[16:22:50] <cwills> The fileserver ran just fine on the btrfs system (as well as the client cache)
[16:24:31] <meffie> i guess the DES key was to support old versions. the ansible role current supports all of the enc types :)
[16:25:36] <wiesand> I'd be surprised if the fileserver wouldn't work on a kind-of-posix-compliant filesystem, including btrfs, at least with light domestic use.
[16:25:59] <kaduk@jabber.openafs.org/barnowl> Yeah.
[16:26:46] <kaduk@jabber.openafs.org/barnowl> Maybe in the 1.4 or 1.6 timeframe we were more picky about cache
partitions for clients
[16:28:04] <cwills> there's an option to turn off some of btrfs's COW that's usually recommended for database or cache directories (or subvolumes)
[16:29:14] <wiesand> Hmm, cache partitions for clients is an entirely issue than backing store for vice partitions, isn't it?
[16:29:50] <meffie> yes, two different things
[16:29:57] <wiesand> "entirely different issue"
[16:30:05] <kaduk@jabber.openafs.org/barnowl> yes
[16:30:51] <meffie> (long ago on solaris, they were not so different)
[16:31:23] <kaduk@jabber.openafs.org/barnowl> "So, about this 'dir' package..."
[16:31:30] <wiesand> well solaris even required the kernel extension on a file or db server
[16:32:01] <meffie> yes, solaris required libafs for the "inode" backend.
[16:32:10] <meffie> that never worked on linux.
[16:32:38] <meffie> namei is used on solaris now too.
[16:33:18] <meffie> anyway :)
[16:33:31] <wiesand> i remember a talk stating that "namei seriously degrades performance"
[16:33:59] <kaduk@jabber.openafs.org/barnowl> You can typically get improved performance by shooting cannonballs
through abstraction barriers, yes.
[16:34:10] <meffie> heh
[16:34:43] <wiesand> (I really liked Adrei, and it's more than sad that he passed away a couple of years ago, but that wasn't his finest hour)
[16:34:53] <wiesand> Andrei
[16:36:17] <kaduk@jabber.openafs.org/barnowl> I updated the commit message for the "revert vos take RO offline"
change, if someone wants to look at it.
[16:37:53] <wiesand> Looks good, but *maybe* authorship should be reassigned to Marcio?
[16:38:29] <wiesand> Nevermind. You already kept that. I just confused the headers.
[16:38:32] <kaduk@jabber.openafs.org/barnowl> Authorship is still Marcio.   Committership gets reassigned by gerrit
at merge-time anyway
[16:38:50] <cwills> looks fine to me
[16:38:57] <kaduk@jabber.openafs.org/barnowl> thanks
[16:39:09] <meffie> +1 lgtm
[16:40:31] <yadayada> lgtm
[16:40:51] <cwills> so.. I have a master/1.9.x question when we are ready
[16:41:12] <kaduk@jabber.openafs.org/barnowl> I think we are ready enough
[16:42:45] <kaduk@jabber.openafs.org/barnowl> What is your question, Cheyenne?
[16:42:47] <cwills> So.. with some of the latest updates, is it time to look at cleaning out the AIX_LINUX20|22|24_ENV code?  Since the minimum is 2.6.10
[16:43:37] <kaduk@jabber.openafs.org/barnowl> IMO that would be a fine thing to do.  I would probably check with
Andrew as well before putting work into preparing something, though.
[16:43:54] <kaduk@jabber.openafs.org/barnowl> We did similar cleanup for FreeBSD versions "recently"
[16:45:09] <cwills> Okay.. I'll bring it up with Andrew.
[16:46:17] <kaduk@jabber.openafs.org/barnowl> Sounds good; thanks.
[16:46:55] <cwills> So I did a build this morning -- master built cleanly with the latest fetch from linux-5.9 (checking 1.8.x right now)
[16:48:27] <kaduk@jabber.openafs.org/barnowl> On my end, I sadly did not manage to pull the trigger on 1.9.0 last
weekend.  I did get a new version uploaded to debian that has the
-fcommon fixes, so that it's not going to get autoremoved, though...
[16:48:59] <meffie> thank you
[16:49:04] <kaduk@jabber.openafs.org/barnowl> I tried to put together some NEWS updates this morning and already
spotted a coupel things that I missed, so that will need a new rev at
least
[16:49:52] <meffie> it looks like some items in the 1.9 NEWS are in the process of being pulled up to 1.8.7.
[16:50:31] <wiesand> Uhuh?
[16:51:26] <kaduk@jabber.openafs.org/barnowl> If 1.9.0 is the first actual release with them, I'm okay having them
in both the 1.9.0 and 1.8.7 release notes
[16:51:28] <wiesand> Please "share early, share often" if you're working on that.
[16:52:23] <kaduk@jabber.openafs.org/barnowl> And since we don't have a 1.8.7pre1 yet, I'm hoping that 1.9.0 will
win that race :)
[16:52:24] <meffie> thanks.
[16:53:01] <wiesand> I'd just love to loose that race :)
[16:53:07] <meffie> lol
[16:53:18] <meffie> it's not a race !
[16:53:56] <wiesand> the guardian called it that ;-)
[16:54:43] <kaduk@jabber.openafs.org/barnowl> Anyway, once buildbot catches up I can merge the revert you asked for.
Were there other things for master/1.9 that I should be looking to get
in before 1.9.0?
[16:54:58] <meffie> not that i know of.
[16:55:26] <kaduk@jabber.openafs.org/barnowl> Okay.
[16:55:34] <kaduk@jabber.openafs.org/barnowl> Motion to adjourn and get back to work? :)
[16:55:56] <meffie> yes!
[16:56:01] <cwills> Sounds good
[16:56:03] <wiesand> Motion to adjourn and start the weekend? :-)
[16:56:28] <kaduk@jabber.openafs.org/barnowl> amendment considered friendly :)
[16:56:49] <yadayada> sure
[16:56:58] <wiesand> Thanks a lot everyone! Have a nice weekend, and please stay safe!
[16:57:03] <meffie> yes, have a good weekend all.
[16:57:13] <kaduk@jabber.openafs.org/barnowl> Yes, thanks everyone, and have a good weekend
[16:58:35] wiesand leaves the room
[16:58:47] cwills leaves the room
[17:00:25] yadayada leaves the room
[17:01:32] meffie leaves the room
[18:31:25] kaduk@jabber.openafs.org/barnowl leaves the room
[19:25:43] mbarbosa leaves the room
[19:26:05] mbarbosa joins the room
[21:33:05] mbarbosa leaves the room