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

[Russ Allbery]

Simon Wilkinson <sxw@inf.ed.ac.uk> writes:
> 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.

I agree with the general problem, although I'll note that in the specific
case of the Debian package, there is a standard location for such
documentation for Debian packages and that location contains comprehensive
documentation of exactly which features are enabled in Debian and where
the files are installed.

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

I definitely agree that this is where we should go.  I don't think we're
quite ready to be there right now, unless you feel that we should enable
supergroups by default.  :)  (I can't reasonably turn it off in the Debian
packages, where it's been enabled for quite some time, without causing
obvious serious problems.)

> If we believe the demand attach is ready then, IMO, it shouldn't be
> hidden behind a configuration switch. If it is, I doubt it will see much
> more use than it does at present.

I'm fairly sure that it will see at least somewhat more use than it does
at present, since I know there are several sites who have been waiting for
the 1.6 release to enable it and start using it in production.  But I
agree with your general concern.

> My current feeling is that it would be great if we could ship both
> fileservers, side by side, with different executable names - but I
> haven't looked at any of the code to see how complex this would be to
> achieve.

I could do that in the Debian packages; it just means building the source
code twice and creating two different binary packages, which is something
that I've done before for other packages and which isn't particularly hard
(just kind of tedious to set up the first time).

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>