[OpenAFS-devel] open issues for an openafs 1.8 branch

[Benjamin Kaduk]

Hi Chas,

Thanks for the reply.  [inline]

On Mon, 29 Sep 2014, chas williams - CONTRACTOR wrote:

> On Wed, 24 Sep 2014 15:14:39 -0400 (EDT)
> Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
> > (2) SONAME bumps for libtoolized shared libraries.
> >
> > We have a handful of shared libraries that we install (most notably,
> > libafsrpc, libafsauthent, and libkopenafs).  The plan is for them to be
> > built using libtool for the 1.8 branch (gerrit 11461, 11462, and 11484).
> ...
> > Does that seem reasonable?  Or should we try to keep consistency with the
> > old numbers?
>
> Has OpenAFS ever been installed with shared libraries by any of the
> packaged installers?  If not, I don't see a reason to bump the
> numbers.  That said, if the API is changed (and changed in a
> non-backward compat way) we of course need to bump the numbers.  I
> would comment that adding a symbol is changing the API and seems like
> it should require an increment.

Debian currently has packages for libafsauthent1, libafsrpc1, and
libkopenafs1 (and the pam modules, which I am discounting for this
question).  They contain only shared libraries, and no static libraries,
which is the standard debian policy.

> > (3) Dropping the Netscape plugin and related bits from our tree
> >
> ...
> > So, do we have consensus in favor of removing these bits from the openafs
> > tree?
>
> It's unmaintainable since it can't be (reasonably) tested.  Remove it.

Yay!  I assume this goes for src/afsweb as well as the bits in libuafs?

> > (4) changing fileserver tuning
> >
> > The fileserver lets you pass arguments like -S and -L for "small" and
> > "large" setups.  But ... the "large" one is actually quite small, by
> > today's standards.  We probably ought to update what those coarse-grain
> > settings do, and the defaults as well.
>
> Good luck with getting agreement about small and large.  Perhaps these
> should be more like the client (with respecting to its auto-tuning of
> the cache size) and use some percentage of memory on the machine.

I thought the users still had to specify the cache partition size in
cacheinfo; what sort of runtime auto-tuning is done?

> > (5) configure arguments for pam/kauth
> ...
> > whether src/kauth bits get installed.  However, the pam modules we provide
> > are only useful in a kaserver-style environment (i.e., krb4).  Currently,
> > pam defaults to enabled, and kauth defaults to disabled, and I have not
> > seen anything to indicate that we wish to reenable kauth for the 1.8
> > branch.
> ...
> > addition to controlling whether the src/kauth bits get installed.  Does
> > that seem reasonable?
>
> Why keep either for the 1.8 branch?  You can stay on the 1.6 stream if
> you need this.  Maintaining stuff that is already done better by others
> (pam_krb5, krb5) seems like a waste of time.

I am given to understand that we need to keep the kauth bits as an option
part of the agreement with IBM that allows us to use the AFS name.  (I
would be all for removing them if that's not the case.)

> > (6) changing default configure arguments/other configure arguments
> ...
> > --help output was pthreaded-ubik.  We believe that what's on master is
>
> Make this the default.  If you don't, it won't get tested in any
> meaningful way.

Agreed; we should find out about any issues with these before people start
using rxgk servers.  (This is gerrit 11483 at the moment.)

> > Going through the output more carefully, I also found --disable-gtx,
> > --disable-uss, --enable-bitmap-later, and --disable-unix-sockets, which I
>
> I don't see the reason for --disable-gtx.  --disable-uss
> apparently exists because of symbol leakage/pollution.  The right
> configure test would be to automatically detect this and just disable
> uss building. The other right way is to fix the leakage.  --disable-uss
> was easier to write of course and did get the job done.  Perhaps it is
> time to split off some of the less popular OpenAFS utilities into their
> own branch.

I'll see if I can take a look at the leakage.

> bitmap-later (and fast-restart) are both just poor versions of DAFS.
> They should be deprecated for 1.8 (accept the options and print a
> warning that the user should switch to DAFS).

Seems reasonable to me.

> I don't know the reason behind unix sockets.  Unix domain sockets gives
> you a different permission model I guess.

Okay.  Anyone else?

Thanks again,

Ben