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

[Jeffrey Hutzelman]

On Fri, 2013-06-21 at 18:05 +0100, Simon Wilkinson wrote:
> 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:
> >> 
> >>> 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.  
> 
> I was just describing dbserver behaviour. I don't think we should be
> supporting transparent downgrades. If someone attempts to run an old
> dbserver against a new database, that old dbserver should fail to
> start.

Agree, with one exception...

> 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 that case, we'd just need to provide an RPC to bump the
> version number. When a server sees the update version number, it
> enables the new functionality.

... if this hasn't been done yet, a transparent downgrade should work
too.




I'm not sure it's realistic for the database format version to remain
scalar forever.  I think orthogonal extensions are entirely possible
(though not really a good idea with the current database format), and
eventually we're going to have to end up with a set of flags or
something indicating supported extensions, with each extension enabled
explicitly via some (hopefully common) RFC.


I also think we need to commit to supporting mixed versions, to an
extent  Particularly, it should be OK to mix versions as long as every
server is new enough to support the database format version in use and
any enabled extensions.  A server should refuse to start if the database
is of a version it doesn't support, and the change-version (or
enable-extension) RPC should fail unless all servers in the quorum
support the new version.

-- Jeff