[OpenAFS-devel] prdb format extension for extended authentication names

Benjamin Kaduk kaduk@MIT.EDU
Mon, 24 Jun 2013 19:33:34 -0400 (EDT)


On Fri, 21 Jun 2013, 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

Sure, and that's why I'm still running 1.4 dbservers on my new wheezy 
machine while I upgrade the rest of the cell.

But, we've never really broken the database format between versions, and 
I'm pretty sure that some people on the lists have reported running mixed 
1.4 and 1.6.  So I don't really think we can claim that no one actually 
does run a mixed environment.

> complete shutdown, upgrade, restart process. I don't think a UUID helps 
> in enough of the edge cases to be worthwhile having.

Yeah, I'm not really convinced there's a need for a UUID.

> 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

That would seem to be the whole point of a version field, yes.  But where 
does one draw the line on "backwards compatible"?  Is it "any new 
feature", or are there edge cases where old servers could still do 
basically sane things when presented with new data?
In particular, I am assuming that you are claiming that the current 
proposal for extended hash tables and data blocks to store extended names 
should get a version bump; please confirm.

> 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.

I think the follow-ups have made this point more subtle; I'll reply to one 
of those.

-Ben