[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

[Jeffrey Hutzelman]

--On Thursday, June 17, 2010 11:38:18 PM +0100 Simon Wilkinson 
<sxw@inf.ed.ac.uk> wrote:

>
> On 17 Jun 2010, at 21:40, Russ Allbery wrote:
>>
>> There is that.  I intend to ship with DAFS enabled for Debian, but the
>> Debian packages have always taken a fairly aggressive approach to
>> enabling features.  (They have had supergroups enabled for quite some
>> time, for example, and also enable UNIX domain sockets for fssync, and I
>> intend to enable disconnected as well.)
>
> This is one of the many problems with having too many knobs that can be
> twiddled. There is no longer "OpenAFS" - you end up with "Debian's build
> of OpenAFS" which behaves in a completely different way to "the RPMS on
> the OpenAFS website", which use completely different paths from "the
> RPMFusion RPMS", which behave differently again to "the Solaris tarball"
> and so on. If you're a new user to OpenAFS, how on earth do you work out
> which set of settings you should be using? Do you know that you're using
> the Demand Attach Fileserver, or whether your package is build with
> Transarc paths, or what the difference between inode and namei is? At
> some point, you'll just give up in disgust.

People who have been at this a really long time, like the GNU project, are 
also very agressive about not having this situation occur.  Absolutely 
anything that can be determined at runtime should be.  The exceptions tend 
to be things that only work if you have some external library to build 
against, cases where it's extremely important to be able to limit binary 
size (for example, monolithic kernels, or programs designed to be used in 
embedded devices), and cases where it's just not realistic to switch 
between two alternatives at runtime.

A good example of the last case, in AFS, is the fileserver storage backend. 
Currently we have somewhere between two and four such backends, depending 
on how you count (some of them are _very_ similar, and otherwise platform 
dependent).  It would be nice to be able to switch between them at runtime, 
or even support multiple backends in the same fileserver.  In fact, not 
having that capability is a major obstacle to transition on platforms that 
support both inode and namei fileservers.  However, it's Really Hard, 
because the code structure assumes there is just one backend and all sorts 
of related behaviors are determined at compile time.  Maybe someday.

At the moment, DAFS is also one of those cases.  Fixing this will require 
quite a bit of work, but I also think it's fairly important.  Hopefully 
someone will find the cycles to make it happen soon.



> I'd really like us to standardise on a _small_ (ideally one) set of
> supported configurations which we suggest for each release - and for the
> binary packages that we point users at to use that set of configurations
> across all platforms. It's the only way that we're ever going to manage
> to produce a coherent documentation set, to provide meaningful advice on
> lists and in chatrooms, and in general, retain our sanity.

+1

-- Jeff