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

[Chas Williams (CONTRACTOR)]

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.