On 6/21/2013 12:55 PM, Jeffrey Hutzelman wrote: > On Fri, 2013-06-21 at 12:06 +0100, Simon Wilkinson wrote: >> On 10 Jun 2013, at 17:24, Benjamin Kaduk wrote: >> >>> I have left out the idea of a UUID attached to the generic extended data >>> for now. I think that the main benefit from such a concept would be if >>> operating in a mixed environment of new and old ptservers, or if it is >>> necessary to revert to the old code for some reason. >> >> At the moment, OpenAFS doesn't support running mixed dbserver >> environments. This is a hangover from the IBM days, but pretty much all >> of our documentation is clear that a dbserver upgrade requires a >> complete shutdown, upgrade, restart process. I don't think a UUID helps >> in enough of the edge cases to be worthwhile having. >> >> There are two things I think we should have to make this easier. >> Firstly, we should actually use the version number, and increase it >> each time there is a change made to a ubik database that isn't >> backwards compatible. Secondly, we should make sure that we don't end >> up with n^2 possible db formats. That means that we should never make >> the ubik database format dependent upon configure flags. That probably >> means that we should just turn on supergroups for everyone. > > Unfortunately, that's a bit too simplistic. It would be really bad if > someone were to upgrade dbservers, have a problem, and then be unable to > downgrade to a working version. That means we have to be careful about > upgrades, avoid using new features unless/until an administrator has > enabled them, and provide tools for downgrading databases. > > -- Jeff
On the subject of SuperGroups I believe that support for the RPCs needs to become a runtime decision but that all OpenAFS distributions should be aware of the SuperGroups DB extensions. That way if the RPCs are not enabled and an entry is removed that previously contained SuperGroups data that the correct removal process can occur. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
