[OpenAFS-devel] Re: [OpenAFS] Re: 1.6 and post-1.6 OpenAFS branch management and schedule
Chas Williams (CONTRACTOR)
Mon, 21 Jun 2010 23:35:10 -0400
In message <2F81C559C509715A17E57424@lysithea.fac.cs.cmu.edu>,Jeffrey Hutzelman writes:
>No; it's much worse than that. Suppose you upgrade to a new version of
>OpenAFS and find there's a serious bug in the fileserver, or ubik, or rx.
>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
>failing. So now you want/have to upgrade.
>Except the new version of AFS in question had supergroups enabled by
>default, and you didn't notice, and some user went and created a
>supergroup. So now you can't back out, because your database is no longer
>compatible with what you were running before. Perhaps you don't notice
>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
>you don't have a ptserver -- maybe you only notice the next day when
>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
>that we ever need to reach a point where existing cells upgrading to new
>code should automagically get supergroups support. Sure, it should
>eventually be turned on by default in a newly-created prdb, but let's not
>unnecessarily break things for people who just want to keep their
>filesystem working, and especially for people who just want to not be
>forced by management to abandon AFS in favor of everyone just giving all of
>their files to Google.
i dont think this case is extreme but afs has typically provided
migration tools in this case (or a strongly worded YOU CANNOT GO
BACK). that appears to be missing in the case of supergroups. again,
i suppose i will hear that 'the review process wasnt up to the job
at the time'. regardless this issue can/should be addressesed now.
otherwise supergroups will have to go away. but we have had the
discussion about why you cant do this.
but you have to draw a line at some point. how far do you want to
take this? should there be sufficient support that i can take my 2.0
filesystems and database and downgrade so i can run my good old 1.0
binaries? i can see providing the ability to go between minor releases
(2.0 -> 1.9) but not requiring 2.0 to provide a utility to go back to
ANY previous release. of course, this is somewhat confused by the fact
that openafs features dont really correspond to any particular release.