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

[Benjamin Kaduk]

On Fri, 28 Jun 2013, Jeffrey Hutzelman wrote:

> On Fri, 2013-06-28 at 14:08 -0400, Benjamin Kaduk wrote:
>> On Wed, 26 Jun 2013, Jeffrey Hutzelman wrote:
>
[supergroups
> Well, there are a number of options....
>
> We could add a command-line argument to control whether to enable the
> feature.  This has two drawbacks.  First, as you note, the default is
> not going to be right for everyone who upgrade.  Second, this makes it
> possible to set the behavior differently on different servers, which
> means the same GetCPS won't produce the same results on all servers.
>
> We could add some kind of flag in the database indicating whether to
> enable the feature.  This doesn't affect the database format; it's just

Well, the database format is affected in that space must be reserved for 
the flag.  But I think what you are saying is that whether or not these 
flags are set does not affect what database structures the running 
software understands.

> configuration indicating how the admin wants the system to behave.  I
> sort of like this idea in general, because it means that policy can be
> changed simultaneously on all servers(*) and without restarting.
> However, with respect to supergroups, it still have the problem you
> describe.

This really feels like the (first) 'flags' word I was proposing.
The DBVERSION value would control what database structures are known, and 
the flags control which ones are allowed to get used.

> We could bump the version number more than once.  Version 1 would be
> today's format without supergroups; version 2 adds supergroups; and
> version 3 adds extended names.  All servers going forward would
> understand at least version 2.  A new server encountering a version 0
> database would have to scan to discover whether the feature is currently
> in use, and then upgrade the version to 1 or 2, as appropriate.

In some ways this feels more elegant than the following...

> Or, for this particular transition, we could simply decide that
> supergroups are now a standard feature of OpenAFS.  All code going
> forward would understand version 0 to include supergroups, and act
> accordingly.  Optionally, we could allow admins to control whether the

... but this is probably more practical.

> server will allow groups to be added to groups (default no); this would
> allow upgrading to a new version without the fear that someone will add
> a group-in-group relationship which prevents downgrading.  The default
> will still be wrong for people already using supergroups, but the
> consequence would be a limitation on the ability to make changes;
> existing data would be processed correctly.
>
>
> Personally, I'm in favor of the following:
>
> - The database format changes linearly for now.  To use a new feature,
> you must
>  have a database version which is new enough to support that feature.
> - Database version bumps are explicit, and are managed via a set of RPCs
> that
>  allow getting the current and maximum supported version and upgrading
> to a
>  version not newer than the maximum.

Agreed.  Can I make you propose RPC names so I don't have to? :)

> - Checking version support before upgrading is handled by the pts
> command that
>  does the upgrade, and a -force flag is provided.

I would have thought that the ptserver would have a better sense of what 
machines are in the ubik quorum than the client running pts, but my 
understanding of how ubik works is spotty.  If you think this is fine, I'm 
happy to go with it.

> - Database format downgrades must be done offline, if they are possible
> at all.

I'm fine with this.  Taken literally, it means that my second "flags" word 
is not necessary, which frees up a bit more space in the prdb header.

> - Reserve some space in the header or elsewhere for storing system-wide
> policy,
>  including whether certain features are enabled at runtime.  This
> doesn't
>  affect the database format, only the server behavior.  These knobs are
> managed
>  via a pair of RPCs that allow getting and setting the value for a
> knob, or
>  perhaps for a list of knobs (perhaps we even permit "get all knobs").
> The
>  set of available knobs is a function of the database format.

Again, space must be reserved to hold these flags, which is part of the 
database structure (and is determined by the db version).  But I think we 
are in agreement on the concepts, just the words are tricky.

>  I imagine that on the wire, a knob has a 32-bit name and a 32-bit
> value.  Of

Would the "name" be an enumeration value, or something like a bitmask 
for the on-disk format?  I guess an enumeration value makes more sense, if 
the reserved on-disk space to hold these things grows larger than a word. 
The values would still all be expected to be representable in a bit or 
two, though.  (Unless we want to get fancy and reserve space outside of 
the header?)

>  course, the range of permitted values will vary from one to another.
> If we
>  wanted to get fancy, we could provide a way to get descriptions and
> permitted
>  values.

I feel like permitted values should probably be baked in with the database 
version (so we wouldn't need a way to get descriptions and permitted 
values).

> - Define version 0 to include supergroups.  New servers always
> understand the
>  database fields used for this purpose and maintain them correctly.
> Whether
>  supergroups are enabled is controlled by a 3-position knob: 0 means
> "no",
>  1 means "yes", and -1 means "yes, but they cannot be created".  The
> default
>  setting is -1.

I'm sort of torn on this.  On the one hand, it's a new structure and there 
are arguments to bump the database version, but on the other hand we need 
a way to transition to the new database version without a full system 
outage.  I'll have to ponder it a bit more.

> So new features will generally require a database version bump and a
> knob to control whether the feature is enabled.  Knobs could also be

Yes.

> used for other things, like controlling the default group quota for new
> users, or whether foreign users are allowed to self-register, or
> whatever.

I'm not sure where the on-disk space for all of those would come from, but 
in principle it could be done.

> Since this is about managing the on-disk database format and controlling
> behavior that is dictated by policy, none of the RPCs involved need to
> be standardized.  They should be documented, of course.

Of course.
I think I will go ahead and submit the document I have to gerrit, which 
tries to document the current format.  That would provide a place for 
future additions to be documented.