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 remember >> 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 distributed >> 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 > 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. > > 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
signature.asc
Description: OpenPGP digital signature