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