[OpenAFS] [Elders] OpenAFS Project List

[Russ Allbery]

Phil Moore <Phil.Moore@msdw.com> writes:
>>>>>> "Russ" == Russ Allbery <rra@stanford.edu>:

> Russ> Yup, having a relational database with information about what's
> Russ> where has been a huge win for us, even though right now we use
> Russ> it almost exclusively for reporting purposes and not to actually
> Russ> drive any management tools.  I'm looking at extending what we're
> Russ> doing further to support things like usage statistics on our
> Russ> software volumes.

> VMS went very, very far, down the opath of automated administration, to
> the point where our AFS administrators almost never even use "vos"
> directly to create volumes.

> In a large scale environment like ours, this was essential, since we
> have a high turnover rate, and keeping people around with the level of
> AFS expertise necessary to get the manual operations right isn't
> feasible.

Yup.  I know how that goes.  We're not in that bad of a turnover
situation, thankfully, but we mostly use a bunch of internal scripts
rather than the raw commands to do most of what we do.

> Russ> Is this the Boxhill vosasm?  I thought that stuff wasn't
> Russ> available any longer?  (We used it for years and years, but then
> Russ> eventually switched to ADSM so that we could get per-file
> Russ> backups and better scaling; vosasm did okay, but Networker
> Russ> itself just wouldn't scale to the size of our cell.)

> Yes, it is.  And yes, networker scalability has not been stellar (I'm
> trying to be nice).  As for availability, I have no idea; you are likely
> correct.

> It is an option, and we'll have to be objective about documenting the
> pros/cons.  Lack of availability will be a pretty big con ;-)

My understanding was that the company that originally wrote it disappeared
and that the people who currently own the rights had both no intention of
ever selling it again and no intention of releasing it to the community.
But the last time I heard anything about this was something like three
years ago.

(Is this still the version using bits written in perl4?)

I kept our copies of the stuff carefully archived, just in case, although
we'll likely never go back to Networker.  But I know that we paid a
permanent license fee for our version and don't have permission to
redistribute it.

> There has never been anything on CPAN, and IM!HO, that is really
> required for wide acceptance in the perl development community.

Agreed.

> This is likely to be the one area where I am able tto contribute the
> most (other than tacking copyrights on existing MSDW code, and tossing
> it over the wall), given my background.

> This, I hope we can deliver on, incrementally, this year.

Excellent.  There are certainly places where we could use that.

If I can dig out from under all the fires and long-delayed projects that
I'm working on *and* wrest some free time from INN development, we have a
bunch of internal tools here that could easily be polished up and tossed
over the wall too.  I've been making noises about that for a while, but
some stuff is getting closer.  The easy stuff (a colorized, more readable
wrapper around vos partinfo and a volume move script that handles
replication, warns about volumes with unreleased changes, picks the least
full partition on a server, and whatnot) is closest.

Probably the most useful program in that category is our tool to summarize
the differences between the read-write and read-only versions of a volume,
which we use to verify all of our software releases.  That one needs a
complete rewrite before really being ready to be released; right now, it's
far slower than it needs to do and doesn't handle root.afs well.  An AFS
Perl module would get rid of a whole bunch of calls to fs lsm.  :)

As soon as the OpenAFS contrib area is available for contributions, I'll
start trying to throw stuff into it.

> Russ> All of our internal tools right now just fork and exec the
> Russ> various standard client programs.

> And that turns out to be the biggest performance bottleneck in the
> larger applications we;'ve developed (eg. behemoth systems like VMS, but
> also simple command line utilities).

Yup.

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