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