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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
