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

[Simon Wilkinson]

On 25 Jun 2013, at 00:57, Benjamin Kaduk wrote:
> So, we would introduce a flags framework with a DBVERSION bump, and =
then allocate flags for new features?

This really does feel like it is unnecessary complexity for now. Until =
lots of people start proposing database format changes, a single =
monotonic version number should serve OpenAFS fine.

> I guess we could steal a couple of words in the header to indicate =
(respectively) "feature supported/enabled by the running quorum" and =
"feature in use in this database".

The problem is that you don't know the feature set supported by the =
running quorum. Only the master can write to the database - so even if =
that updates the database with its feature set every time it is =
restarted, the slaves get no say. One of the challenges with Ubik is =
that there is currently no mechanism to do configuration negotiation =
during a quorum election. So there's no way to notice during that =
election that a slave's configuration is non-standard.

This problem also arises when discussing what to do with backwards =
compatibility. Even if it is possible to allow "old" servers to continue =
to read, but not write to, the database, it is only safe if they provide =
exactly the same results as "new" servers. For example, running a cell =
with a mixture of servers with and without supergroups isn't safe even =
in read only mode, because the results of pt_GetCPS will differ =
dramatically depending upon which database server the file server is =
talking to.

> I am deliberately not making a concrete proposal for how to handle the =
supergroups transition right now;

There isn't a "supergroups transition". The current supergroups =
implementation is an unavoidable fact of our current database version - =
we have to assume that all of the supergroups fields are occupied in all =
databases with that version, and our recovery tools have to deal with =
the imperfections of the way supergroups are currently stored.

I think all of this only really comes into play when we're discussing =
how to store GSS names within the database. And it seems to me that the =
simplest way of doing that is with a controlled version number bump.

Cheers,

Simon