[OpenAFS] 1.4.x quorum election process?

[Jeffrey Altman]

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

On 10/26/2011 2:21 PM, Jeff Blaine wrote:
>> Think about what you would need to do if you were running with this
>> patch locally.  Every sysadmin that upgrades these servers must rememb=
er
>> that the patch is in place (or how the servers were built/configured)
>> and not forget.  If you leave tomorrow, is the next sysadmin going to =
be
>> burned by this change when s/he attempts to install openafs distribute=
d
>> binaries in your cell?
>=20
> You could make the same argument (that you're making) with
> at least 5 other existing OpenAFS command-line or build-time
> options.  Example: --enable-namei-fileserver vs. not, drop
> on a server with existing vice partitions in the wrong
> style.

We have spent the last five years removing compile time options.  Inode
vs Namei is a particularly bad example since two things have been
happening in the file server back-end processing:

1. Consolidation of code trees to permit more run time functionally
selection

2. A decision to not accept additional back-end implementations such as
POSIX-Extended-Attributes or HostAFS without also abstracting back-ends
so that a file server can choose which back-end it wants to use at
run-time on a partition by partition basis.

One of the rationales for this is permit sites to migrate from one
back-end to another on the same file server hardware without requiring
that all volumes to relocated to another server as a transition.

> Build/implementation decisions are encapsulated in build
> scripts of ours.  Additionally, those decisions are documented
> in our wiki.  If he/she hasn't read our internal documentation
> about our cell, which is extensive and clear in our wiki, then
> yes, he/she will get burned.
>=20
> Just like he/she would with any other option for cell
> or server configuration.

Then you can happily maintain the patch locally since it makes a change
to three lines of source code.

There has been discussion over the last several years about what such a
change should look like especially as we move to a world that includes a
mixture of IPv4 and IPv6 as well as the possibility that multiple
service instances could exists on the same machine with different port
numbers.  Such a configuration could be deployed today using DNS SRV
records for any of the database services.

I don't remember all of the details but I believe the agree upon
solution included:

 * UUIDs for each database service instance

 * Configuration data that would be deployed in conjunction with a new
   CellServDB format that would specify the ranking

 * Some hash of the configuration data that would be included in the
   votes to ensure that only votes that are cast on the same ballot
   are included in the resulting decision for those that agree upon
   the ballot.

Where are we on this?  Well,

 * Simon Wilkinson [YFS] has spent time working on implementing the
   new CellServDB file format that was agreed to at the most recent
   AFS hackathon.

 * There is agreement that mixed version database servers are not
   supported within a cell and that ubik is not an afs3-standard
   protocol and as such does not require protocol standardization
   for the purpose of making changes.  That is not to say that OpenAFS
   will permit a change to be accepted without a solid protocol
   description but it does make it easier for OpenAFS to accept and
   roll out changes as part of a version number upgrade.

 * Filling in the rest of the pieces such as assigning UUIDs is not
   an overwhelming amount of work.

Anyone that is interested in contributing to this work with code or
financial support is welcome to contact me privately.

Jeffrey Altman


--------------enigBDD23B360DDF565D7266E488
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)

iQEcBAEBAgAGBQJOqH7tAAoJENxm1CNJffh4ZiMIAIUXaUBFx5l4sguLe3q3OrqV
JrcyhPXM5CGkqcMPCzqkoIz4fTJ63QD+FcN7x/CLXxGBazfKHzOtivL9N1BCBqRR
+O0D8KIkVdCCAYJYuuqr+K0av3rttm2+qo++ZUj3ZpHSyAqFsMI8tZUflN8gWV/b
QgxbnLq7tHU6Jb0Xkvltri4ayD78qMhLSmz0pJB2NgLrHRxJ9xPMut4k05R5gJDb
xMA/mts3Sws8x73px6CSQZ5ziA9snjGafxFxVrD9JY7cSJzwLcJ/YsuUfmEtDhH6
L3urUFqJRDIyNmAFz3bPPnaNd+k+ybe/nY5bQWvQrR3soSWMnCTc3NuhKxqzkZg=
=uMoS
-----END PGP SIGNATURE-----

--------------enigBDD23B360DDF565D7266E488--