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

[Benjamin Kaduk]

On Wed, 26 Jun 2013, Simon Wilkinson wrote:

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

That's fair.  No need to make too much extra work for ourselves.

Do I then conclude that my proposal is fine, except that it should bump 
DBVERSION to 1?  We would need to resolve the details of how an update 
would occur, if we don't want to require simultaneous update of the 
software on all dbservers, of course.

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

Perhaps I am confused, but I was expecting that:
(1) something (perhaps administrator action) causes the master dbserver to 
decide that it should try to enable a feature flag.
(2) something (maybe the administrator, maybe the master dbserver itself) 
calls an RPC against each server in the quorum, individually, to query 
support for that feature.
(3) If all servers in the quorum report success, the master dbserver makes 
a write indicating that the feature is enabled
(4) subsequent slave dbservers attempting to join that do not support the 
indicated feature notice that the flag is set and decline to join the 
quorum.

How does that go wrong?

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

Right.  If feature X is enabled in the prdb but dbserver B doesn't know 
about feature X, dbserver B should shut down (or effectively shut down).

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

Some people in this thread were advocating that, going forward, running 
dbserver software always know about supergroups (as opposed to being able 
to compile away support for them).  This is a behavior change, and I am 
not thinking about what its details should be or how to implement it, 
right now.

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

Okay.  There's nothing wrong with setting DBVERSION=1 for extended names, 
and then later deciding that we want to move to flags as DBVERSION=2, as 
far as I can tell.  Maybe jhutz disagrees, but we'll see. :)

-Ben