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

[Benjamin Kaduk]

On Fri, 21 Jun 2013, Jeffrey Hutzelman wrote:

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

So, we would introduce a flags framework with a DBVERSION bump, and then 
allocate flags for new features?
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".

I know that the ZFS zpool version 28 introduced feature flags and the 
departure of a monotonic version number; it seems like we may follow a 
similar path.

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

Feature flags would seem to allow mixed version support (going forward, at 
least).  Old servers would fail to start with DBVERSION 1, and servers 
that know about DBVERSION 1 can check the flags word(s) to see whether all 
of the flags in the DB are ones it understands.  We'd have to make sure we 
don't paint ourselves in a hole with a 32-flag limit, but that does not 
seem too hard to work around.

In terms of RPC support, we could have a GetFeatures call (GetCapabilities 
is taken?) that returns a variable-length array of 32-bit words holding 
the flags the running software knows about, and an EnableFeature RPC that 
sets one of those flag bits, coordinating through the sync site.  That 
would set the flag in the first of the header fields, that the running 
quorum supports the feature; the bit would not get set in the second field 
until it is actually used (e.g., the first supergroup entry is created). 
During that interim state, a variant of the EnableFeature RPC (or a 
separate DisableFeature RPC, I suppose) could do the obvious thing.

I am deliberately not making a concrete proposal for how to handle the 
supergroups transition right now; I'd like to get a better handle on the 
general question, first.

-Ben