[OpenAFS] 1.4.x quorum election process?
Wed, 26 Oct 2011 17:43:08 -0400
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=UTF-8
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=
>> 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 =
>> burned by this change when s/he attempts to install openafs distribute=
>> binaries in your cell?
> 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
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
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.
> 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
* 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
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
* 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.
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)
-----END PGP SIGNATURE-----