[fedfs-utils] Fwd: Re: Proposal for end-of-life for fedfs-utils development

[Ian Kent]

Sorry, my bad, hit reply instead of reply-all.

-------- Forwarded Message --------
Subject: Re: [fedfs-utils] Proposal for end-of-life for fedfs-utils development
Date: Thu, 3 Aug 2017 11:25:09 +0800
From: Ian Kent <raven at themaw.net>
To: Chuck Lever <chuck.lever at oracle.com>

On 02/08/17 22:02, Chuck Lever wrote:
> 
>> On Aug 1, 2017, at 8:40 PM, Ian Kent <raven at themaw.net> wrote:
>>
>> On 07/06/17 23:55, J. Bruce Fields wrote:
>>> So if it's not too depressing I'd be curious what went wrong--did this
>>> turn out to be harder than we thought to get stable, or are people happy
>>> enough with automounting, or did we just not do a good job of explaining
>>> it to people that might use it, or some combination of all those?
>>
>> Having had to setup a test environment to check how things work a couple of
>> times I must admit I found it a bit difficult to use. But perhaps that's
>> because a test setup needs an LDAP server and a DNS forwarding server for
>> the SRV records.
>>
>> Now I'm wondering if it would be worth adding some (quite a bit actually) of
>> this to autofs.
>>
>> The problem that comes to mind is that to eliminate the need for the FedFS
>> management utilities would mean a fair amount of work in autofs. Then there's
>> the need for an nfsref(8) that supports FedFS referrals which probably doesn't
>> quite fit in autofs and without it the rest doesn't seem worth doing.
>>
>> My thoughts about what I can do are still forming and now I'm wondering what
>> others that care about this functionality think about it.
> 
> We wouldn't carry all of the FedFS functionality forward. Basically
> everything that is related to LDAP would be deprecated.
> 
> There are two main pieces left.
> 
> -> The DNS SRV piece needs either mount.fedfs or equivalent autofs
> functionality. The tool for managing domain roots is nothing more
> than syntactic sugar. No need to carry it forward.

Right, I was planning on pulling in mount.fedfs almost unchanged and
writing a fairly simple autofs mount module to call it. That's shouldn't
be much of a problem. Not sure if mount.fedfs should live within autofs
or be placed in the sbin directory, for the moment I'm assuming it will
live within autofs.

I was also thinking of writing a lookup module that essentially implements
the program map. That shouldn't be too hard either.

And including the relevant schema should be sufficient for people to add
the referral entries to whatever LDAP server they are using so that doesn't
appear too much of a problem either, other than a README.fedfs.

Not sure there's a lot more that's needed to provide minimal support while
people migrate or continue to use what they have ... am I correct?

> 
> -> nfsref can manage basic referrals, which don't require any LDAP
> support. nfsref and the junction library could be moved into nfs-utils
> to support basic referrals.
> 
> In other words the only piece autofs needs is support for /nfs4.
> The NFS-server piece would reside in nfs-utils.

That's what I was asking I guess.

I'm not really concerned where this lives just need to know for my
planning and also what capabilities it will retain for FedFS referrals.

I guess I should have a look at nfsref and the junction libraries...

> 
> Walking away from all of it is an option too.

Sure, whatever I do will be minimal, I'd just like what is done to
function.

Ian