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.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
