[OpenAFS-devel] Re: [OpenAFS] Re: 1.6 and post-1.6 OpenAFS branch management and schedule

[Tom Keiser]

On Fri, Jun 18, 2010 at 2:56 PM, Chas Williams (CONTRACTOR)
<chas@cmf.nrl.navy.mil> wrote:
> In message <20100618093541.46bc13bc.adeason@sinenomine.net>,Andrew Deason=
 writes:
>>It's pretty easy to make a supergroup if it's turned on; you may not
>>realize it's a specific feature to turn on. Once you have done so, your
>>ptdb is now incompatible with ptservers without supergroups enabled.
>
> this might happen if you ran mis-matched servers. =A0but best practices
> would tell you this is a bad idea.
>

I think it's considerably worse than that: let's suppose,
hypothetically, that it turns out there's a serious bug in the
supergroups code, and the easiest solution is to downgrade to a
non-supergroups enabled build.  Well, unless you know how to hex edit
your prdb to remove the group-in-group membership pointers, you're
effectively out of luck...

Speaking of which, can I propose that over the next few years we move
to a model where including code in the build does not implicitly
enable it?  Active Directory is a common example of this model: they
typically decouple code upgrades from schema-changing feature
enablements--it is up to the administrator to decide when to "throw
the switch" to enable  backwards-incompatible features, despite the
fact that the code may have supported it for some time.  If/when we
modify the on-disk format, we're going to run into the same issues,
and I'd love to have a plan in place ahead of time to deal with
this...

-Tom