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