[OpenAFS-devel] Re: [OpenAFS] Re: 1.6 and post-1.6 OpenAFS
branch management and schedule
Mon, 21 Jun 2010 19:32:27 -0400
--On Friday, June 18, 2010 04:17:19 PM -0400 Tom Keiser=20
> On Fri, Jun 18, 2010 at 2:56 PM, Chas Williams (CONTRACTOR)
> <email@example.com> wrote:
>> In message <firstname.lastname@example.org>,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. =C2=A0but best =
>> 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...
No; it's much worse than that. Suppose you upgrade to a new version of=20
OpenAFS and find there's a serious bug in the fileserver, or ubik, or rx.=20
Or you missed some "crucial" process step and so it "wasn't OK" to upgrade. =
Or someone decides that your upgrade was the cause of their hard disk=20
failing. So now you want/have to upgrade.
Except the new version of AFS in question had supergroups enabled by=20
default, and you didn't notice, and some user went and created a=20
supergroup. So now you can't back out, because your database is no longer=20
compatible with what you were running before. Perhaps you don't notice=20
until you actually tried to run the old code, and it just didn't work. You =
don't know why it's not working; you may not even notice right away that=20
you don't have a ptserver -- maybe you only notice the next day when=20
someone can't access any of their protected files.
OK, perhaps that's a bit extreme. But maybe not. It's not clear to me=20
that we ever need to reach a point where existing cells upgrading to new=20
code should automagically get supergroups support. Sure, it should=20
eventually be turned on by default in a newly-created prdb, but let's not=20
unnecessarily break things for people who just want to keep their=20
filesystem working, and especially for people who just want to not be=20
forced by management to abandon AFS in favor of everyone just giving all of =
their files to Google.