[fedfs-utils] Proposal for end-of-life for fedfs-utils development

[Chuck Lever]

> On Aug 2, 2017, at 11:27 PM, Ian Kent <raven at themaw.net> wrote:
> 
> 
> 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?

The /nfs4 part of this uses only the DNS SRV record. No LDAP
query is done for this (unless the DNS server is doing one).

This points NFS clients to the server and export where the
top-level directory resides. From that point, NFS referrals
guide the clients through the file namespace.


>> -> 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.

It would no longer support FedFS referrals. Only NFS basic
referrals would be supported.

When an NFS server resolves one of these objects, it will not
perform any LDAP query. It will use only the information in the
junction object.

My sense is that no-one has deployed FedFS. Deprecating this
functionality should be safe.


> 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

--
Chuck Lever