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

[Chuck Lever]

> On Aug 2, 2017, at 10:02 AM, Chuck Lever <chuck.lever at oracle.com> 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.
> 
> -> 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.
> 
> Walking away from all of it is an option too.

I see that openldap-server is deprecated in RHEL 7.4:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html

The FedFS LDAP components relied on openldap-server, so I
guess it's a good thing they are going away too ;-)


>> Thoughts?
>> 
>>> 
>>> --b.
>>> 
>>> On Fri, Jun 02, 2017 at 11:01:05AM -0400, Chuck Lever wrote:
>>>> Upstream fedfs-utils has not been under active development for
>>>> two years or more, and there is a scant user base. I'd like to
>>>> propose making 0.10 the final major release of fedfs-utils.
>>>> 
>>>> The plan:
>>>> 
>>>> - Since 0.10 is in at least one major enterprise distribution,
>>>> I will remain available to integrate security fixes and make
>>>> new minor releases in the 0.10 line, as needed, for one to
>>>> two more years.
>>>> 
>>>> - Retire and remove fedfs-utils from upstream mirror distros
>>>> such as Fedora rawhide.
>>>> 
>>>> - Transfer utilities such as nfsref into nfs-utils, with
>>>> support for FedFS junctions removed.
>>>> 
>>>> - Announcements of the change in status will be made on
>>>> fedfs-utils-announce and on the wiki.linux-nfs.org site.
>>>> 
>>>> 
>>>> 
>>>> Comments welcome!
>>>> 
>>>> 
>>>> --
>>>> Chuck Lever
>>>> 
>>>> 
>>>> 
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> 
>>> _______________________________________________
>>> fedfs-utils-devel mailing list
>>> fedfs-utils-devel at oss.oracle.com
>>> https://oss.oracle.com/mailman/listinfo/fedfs-utils-devel
> 
> --
> Chuck Lever
> 
> 
> 
> 
> _______________________________________________
> fedfs-utils-devel mailing list
> fedfs-utils-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/fedfs-utils-devel

--
Chuck Lever