--On Sunday, February 07, 2010 06:53:46 PM -0500 Jeffrey Altman
<[email protected]> wrote:
On the other hand, if we take the approach that the PR database must be
uniform across the cell, why do we need to avoid sending requests from
the cache manager to the PR service? The PR service is not like the
Vol service which is never contacted by a client. While the PR service
is not contacted by the cache manager, it is contacted by other client
processes: *klog, fs examine, Windows Explorer Shell extension, etc."
Is there a protocol reason to avoid sending requests to the PR service?
Having the CM send requests to the PR service will add a fair bit of
complexity to the OpenAFS CM implementations, which currently do not track
the status of ptservers. This problem probably gets worse when you start
considering support for SRV records, both because they allow defining
separate sets of servers for each service, and because they allow the use
of non-default ports.
On the other hand, the CM also does not currently send authenticated
requests to vlservers. Even in a world where CM's are keyed and do send
authenticated requests to vlservers, there is currently no expectation that
they will maintain separate vlserver connections for each user, and I'd
rather we think about that before increasing the vlserver's connection load
in that way. It shouldn't be too bad, but could be a factor of 100 or more.
I'd also prefer not to create a VL->PR dependency for this purpose.
By contrast, it seems like it would be fairly simple for the CM to call
RXAFS_WhoAmI as part of setting up a new fileserver connection, remember
the answer for each connection, and copy it into the axs cache entries.
This resolves the question of what fileserver to ask, restricts the use of
each fileserver's answer to the axs cache entries corresponding to rights
advertised by that server, and eliminates the need to add a PR dependency
to either the CM or vlserver.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
