[AFS3-std] Standardization of GetCapabilties RPCs for AFS3 client and services

[Tom Keiser]

On 2/24/06, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
>
>
> On Friday, February 24, 2006 06:28:28 PM -0500 Chaskiel M Grundman
> <cg2v@andrew.cmu.edu> wrote:
>
> >> (5) In addition to advertising new functionality, the Capabilities fla=
gs
> >>     can be used to provide hints to the caller of behavior the server
> >>     may desire.  For example, a file server may prefer that client not
> >>     request make SetLock requests even though the functionality is
> >>     supported.  These hints would not be mandatory and would simply be
> >>     a method by which desired policy can be distributed from server to
> >>     client.
> >
> > Why is it a good idea to put client policy configuration in the server?
>
> In general, it's not.  However, it is appropriate for a fileserver to
> provide hints about what functionality it will support, or what access
> control policies it will apply, particularly in cases where that helps th=
e
> client to provide a better user experience.  For example, it may be helpf=
ul
> to a client to know whether the fileserver supports mandatory locking, an=
d
> under what circumstances it will grant such locks, in advance of actually
> trying one.
>
>
> In general, capability bits should be used to describe how the entity
> advertising the capability will behave; they should not be used to tell t=
he
> querying entity how to behave.  If you want all the clients you manage to
> have a particular policy, then distribute policy configuration to them vi=
a
> a suitable mechanism, not by overloading server capapbility negotiation.
>

I mostly agree with this.  However, we have a bit of a problem given
that there is not necessarily any relation between the fileserver
administrator and the cm administrator.  As the protocol matures,
there will be parameters for which we will want finely granular
control.  For instance, if a cell wants to migrate to the
SetLock-on-open code path, they will want tunables that permit a slow
migration.  Ideally, such tunables would be per-volume, but
per-fileserver may have to suffice.

Attempting to disseminate this type of finely granular policy state to
the clients themselves would become an unwiedly distribution problem,
and an effectively intractable distributed coherency problem.=20
Furthermore, it is unclear how such policy data would be communicated
to cache managers under external control.  I'm not sure we can rely on
out-of-band policy distribution for everything.

As an example, varying the behavior of SetLock-on-open on a per-cm
basis is totally orthogonal to what is desired.  The value of this
tunable parameter should be dependent upon the ACL configuration of
the volume, locking capability of the fileserver, and byte-range
locking capability on the client.  In order to produce policy
attributes this flexible I think we need a new class of policy that is
server-{mandated,hinted}.

I agree that using capability bits to fix this problem seems
incorrect.  Perhaps the appropriate thing to do is have a
"capabilities" namespace, and a separate "policy" namespace?

I think the need for servers to give hints (and mandates) to clients
will only increase.  There are sites who want the ability to, for
instance, mandate encryption (and eventually enctypes) on a
per-fileserver, or (ideally) per-volume level.  I've also heard
interest in bits to mandate: non-cacheability, that data must be
cached in encrypted form, etc.  We need a mechanism for telling
clients about such policies.

It does seem odd to have servers pushing policy to clients, but most
of the use cases I can think of would be difficult to achieve in
another manner.  I suppose all of this could be implemented with some
sort of centralized policy database, but that sounds very DCE-ish and
outside the scope of AFS.

Regards,

-Tom