[OpenAFS-devel] Re: [OpenAFS] Re: 1.6 and post-1.6 OpenAFS branch management and schedule
Thu, 17 Jun 2010 19:27:02 -0400
if we do this, we should consider naming the dafs servers something
else. then the binaries can truly coexist and be documented as such
(not just packaging-renamed)
On Jun 17, 2010, at 7:09 PM, Andrew Deason <firstname.lastname@example.org>
> On Thu, 17 Jun 2010 23:38:18 +0100
> Simon Wilkinson <email@example.com> wrote:
>> 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
>> 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 think it could help this a lot if we had some better way of knowing
> what options you have with given binaries, too. I mean, the answer to
> "is my fileserver binary namei" is typically "strings | grep", which
> seems silly to me. We need a '-V' or something that prints out the
> configured options information.
>> I'd really like us to standardise on a _small_ (ideally one) set of
>> supported configurations which we suggest for each release
>> 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.
> But can't we recommend the use of configuration switches that are not
> the default? For example, even if it's recommended, DAFS is going to
> a surprise for someone who's just using the same ./configure options
> they always have, and don't know about DAFS.
> A third option is also not to have either be the default, and refuse
> build unless someone says --enable-demand-attach-fs or
> --disable-demand-attach-fs . That sounds a bit crazy to me, but I'm
> throwing it out there.
>> 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
> I haven't actually tried this... but at least from the perspective of
> the end result binaries, this seems simple. (the build process will be
> annoyingly longer, though, at least).
> 1.5 bosserver always understands the 'fs' and 'dafs' bnodes, I'm
> sure, regardless of whether DAFS is enabled or not. So you can have an
> 'fs' bnode pointing at the non-DAFS binaries, and a 'dafs' bnode
> pointing at the DAFS ones. You should be able to switch between DAFS
> non-DAFS just by stopping and starting the fs and dafs bnodes.
> Andrew Deason
> OpenAFS-devel mailing list