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

Simon Wilkinson simonxwilkinson@gmail.com
Fri, 21 Jun 2013 18:05:03 +0100


On 21 Jun 2013, at 17:55, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> On Fri, 2013-06-21 at 12:06 +0100, Simon Wilkinson wrote:
>> On 10 Jun 2013, at 17:24, Benjamin Kaduk wrote:
>>=20
>>> 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 ope=
rating in a mixed environment of new and old ptservers, or if it is necessar=
y to revert to the old code for some reason.
>>=20
>> 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.=20
>>=20
>> 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.
>=20
> 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. =20

I was just describing dbserver behaviour. I don't think we should be support=
ing transparent downgrades. If someone attempts to run an old dbserver again=
st a new database, that old dbserver should fail to start.

We should provide offline tools to perform downgrades.

There is an argument that just installing a new database server shouldn't be=
 enough to enable new behaviour, to permit upgrades without downtime. In tha=
t case, we'd just need to provide an RPC to bump the version number. When a s=
erver sees the update version number, it enables the new functionality.

Cheers,

Simon