[OpenAFS-devel] Some low-hanging RPC fruit vs long-term needs

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6DC04048C210A171AB6E7E34
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12/16/2010 2:13 PM, Steve Simmons wrote:
> The version report we get from rxdebug -v is useful, but as others note=
, it can and is set by various sites to reflect their local needs. A 'cor=
e version' flavor that strictly follows AFS releases would be useful, eg,=
 rxdebug -coreversion would only report a string the user shouldn't muck =
with. And yes, I know that git-ish things have to be considered, yadda, y=
adda. The devil is always in the details.

The bigger problem is that the version number of the RX library has no
relationship to the version of the service that is running on top of RX.
While it is true that the current OpenAFS servers using static linkage
on UNIX, this is not true on Windows and is not necessarily true for
alternative implementations of the AFS3 protocols.

The appropriate place for structured version information is in each of
the RX RPC client and server modules.  The server needs to know what
version the client is in order to understand how to work around client
bugs and the client needs to know what version the server is in order
work around server bugs.

The Capabilities RPC could be replaced with a version that requires that
the initiator advertise its version and get back the version of the
peer.  However, I do not believe that making use of such knowledge is a
panacea.  For starters, adding code to work around past bugs increases
the complexity of the code.  Not only for those that are reading it but
for those that must test it in the future.  We have too many code paths
that cannot be tested today.  How are we supposed to test that the bug
avoidance code paths continue to work in the future?

Another concern of mine is that version numbers are local.  I know sites
that have patched the version string to report a magic version number
that is unrelated to the release they are based upon because policy
states that they can't "upgrade" but they are permitted to fix bugs.
Since their servers are contacted by publicly distributed clients, the
clients may begin to execute code paths based on version number that is
completely inappropriate.

Even in less extreme cases, if you have 1.4.12 servers deployed today
and you discover a bug and patch it, how are you going to locally modify
the version number to reflect that?  If you do modify it, then the bug
work arounds for 1.4.12 will stop being triggered and if you don't
modify then 1.4.13 clients that have a work around for 1.4.12 will begin
to avoid a bug that you have already patched.  Since you do not control
the deployment of clients you can't ensure that there will be
synchronization between when you deploy 1.4.13 and the new clients show
up at your server's door step.

In any case, this problem is not for OpenAFS to solve on its own.  Any
RPC work needs to be handled by the AFS3 standardization community.  The
appropriate place for any design work is on their mailing list.

Jeffrey Altman



--------------enig6DC04048C210A171AB6E7E34
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJNCoucAAoJENxm1CNJffh4Q8MH/R71bTWfuHCQXLxnFex7ZZzv
hKEPoCilFZK0+nNhcrQE9kpnZOhUpZJGcXVJ7hck0Ey58nNHAV09pd6+LKOJxNfS
FD/DmH0beRGZyftBN8Repm0md+WJEXix3uglzq++OyemZjr0UtO0dnk/v97amtE9
p8QEU/r/gY7dY7qef4ssBBgfNVt1dvhCJnVmKOv2glZWd7qydOCcoAqiNMe67LUd
rAEWXvdKzb0QYl7XBTu5Q7olOgDjB2uOkeyyHG6f8wgXE3wNi8p0O5TP1wOntDNA
7zCkOCtT+1DY1fTA5NUKXQJtccsblKUhcTuVgu730tccNjKkIiqGuk+5cCR5iaY=
=Qeci
-----END PGP SIGNATURE-----

--------------enig6DC04048C210A171AB6E7E34--