-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Simon,
In general, I am of the belief that prescriptive rules, here specifically, the proscription sites _should not have_ site local ACL bits, disregarding precedent (the entire history of AFS), should have to meet a far higher standard than 4 people on this list oppose (while at least 3 have publicly supported, and more support is, of course, out there for this feature than has weighed in.) Rather obviously, it should take more than a simple majority of folks not seeing the purpose of some feature, when one of the largest and most significant OpenAFS deployments historically and today, worldwide, sees its merit enough to code and maintain it. To me, the discussion on principle (and the principles of sound reasoning) are what matters. I think that anyone who read Jeff Hutzelman's post should have come away with the realization that there are important matters of principle at issue here. Here is my summary, amplifying it with some more: * OpenAFS needs to stay true to its history, as well as move forward--that means it needs to take account of the needs of sites like CMU and (redacted, their preference, this is Derrick's convention of representing it)--to do otherwise is really unwise (I easily could add more adjectives here) * The argument for "uniformity" and against site-local flexibility seems to be a proxy for a much larger argument against diversity in the code base, against OpenAFS being more things to more people, where no one is harmed--the shifting of the argument to be against "too many configuration options" is the evidence for this Turning to that, the argument against "too many configuration switches" is rather like the argument that Mozart used "too many notes." Too many for what? Clearly, we should keep all the switches activating the features that the product and its developers need--all the rest are superfluous. Just as clearly, "too many configuration switches" is a proxy for blanket attacks on all the features _you_ don't see the need for, but others (who created them) did. More importantly, as I amplify further in my inline comments, the attempt to justify reduction by reference to maintainer testing obligations is specious, on multiple levels. OpenAFS gatekeepers don't need to test all the features the product can theoretically perform, they only need to test the ones that are _officially supported_. To argue otherwise is, respectfully, some type of overreaching. The simple truth is, OpenAFS has a lot of developers working on features that need to see wider use, need to see the light of day, and need to be committed to the main line of OpenAFS development. The message we developers need to hear is that OpenAFS and its community and leadership are eager to incorporate as many of those features as it possibly can. We don't need to hear the message that there are too many configuration options in OpenAFS--by all means, solve our testing problems, solve them PLEASE. Or appoint some of us to help solve them. But respectfully, we have, collectively, a right to expect the solutions to be the best available, to be sensible, flexible, and well reasoned. I have always assumed the fair bargain for the right to add new concepts and implementations to the system, was that I not act to _prevent others_ from adding features for which they see the need and benefit, but which I, in my ignorance, do not. That is the ecumenical spirit, or, if you will, the humility, that essential to our future progress as a community. Matt ** In line comments follow: Simon Wilkinson wrote: > > On 8 Dec 2008, at 17:46, Jeffrey Hutzelman wrote: > >>> and "is the OpenAFS community prepared to revoke the site >>> local ACL bits so that there are bits available to assign to a standard >>> function?" >> >> No one's suggesting that should happen. > > This has been discussed. I don't think anyone believes that it's a > realistic option at this time, but it's certainly been bandied about. It should not have been, for reasons adduced here and in our previous mails. > > > Remember, we're not just talking about different sites, but also about > potentially different semantics amongst servers at the same site. We're > also talking about a situation where the meaning of a private use value > can differ between two otherwise identical builds of the same product, > at the same site. This reasoning is not cogent. It is the responsibility of site administrators (or their contractors, or whatever) to establish and maintain a uniform deployment of OpenAFS servers--or indeed, to be quite frank, their prerogative to establish and maintain whatever configuration of OpenAFS servers they darned well like. > > >> which always presents these bits as ABCDEFGH, regardless of what they >> mean. If you think that's too confusing, I could certainly work up a >> proposal for protocol extensions to allow clients to discover more >> descriptive names for these bits, though I have no idea what the UI >> for 'fs sa' would look like, or what a reasonable implementation in >> OpenAFS would look like. > > Such an extension would remove some of my concerns - but rather than as > an optional extra, I'd say it's pretty much essential to have it before > this kind of feature is implemented. I'm glad you can see your way to this. Perhaps there is an unburdensome way forward. > > > But the use of these bits isn't incorporated into the OpenAFS code. > Using site extension bits currently requires that an administrator is > very aware that they are deploying a local extension, and of the > ramifications of doing so. Incorporating these extensions into OpenAFS > normalises their use, and I think that is highly undesirable. In my > view, the use of site local bits should require site local patches. You have not established that requiring external patching is the only effective way to communicate the message "you should think carefully before enabling this optional feature, foolish mortal" to site administrators _custom building OpenAFS from source_. Here is sound reasoning (fixed that for you): * building OpenAFS from source carries with it acceptance of the responsibility for 80% of the consequences * the OpenAFS gatekeepers carry the remaining 20% of the responsibility for the consequences, and they may fully discharge it by: ** making OpenAFS build in the safest, most universal configuration for the supported platform being build, by DEFAULT ** they may discharge an additional 15% (adding up to 115%!) of their responsiblity to protect users by adding "**DANGER Will Robinson! Danger!** to the --help output for each terrible feature like the proposed, which we commit into OpenAFS > >>> Unfortunately, the reality is that increasing the complexity of the >>> OpenAFS build system to support site local patches >> >> No one's suggesting increasing the complexity of the build system. > > The core problem is that it increases the complexity of building, and > deploying OpenAFS. You now have to ensure that all of your fileservers > are built with the same set of options. If they're not, you have to be > careful of moving volumes around between fileservers. This isn't a huge > issue when you're just discussing one site-local bit. But, when we've > got one, why not accept more? And then you really do end up with a > twisty-turny maze of configuration directives. Building and deploying > OpenAFS is complicated enough already - let's not make it more so. I think you should re-read your argument here, it is again, uncogent. The premise that sites cannot be trusted to coordinate uniform build and release cycles, such that uniform build configurations, and indeed, a uniform set of OpenAFS program binaries are in use at each release they roll out, is simply not credible. It is a false premise. Add to that, OpenAFS actually _builds releases for them_ following whatever supported profile it prefers. There is no twisty maze of anything being presented to users or administrators. > >> No, it doesn't ease the testing burden, much. But it _does_ ease the >> maintenance burden, because it means I don't have to spend days >> hand-integrating changes before I can even begin testing. As I said, >> I've been there, and I don't ever want to go back. > > If the code is never built, how can you tell that it's still working? > I've been pushing for a while for a reduction in the number of --enable- > options, especially for little used code. If we're going to move forward > into a world where automated regression testing is the norm, this is > going to be more and more important - we simply won't be able to build, > let alone test n^2 different configuration sets. The problem with this argument is that it too is uncogent. We/you/the gatekeepers do not carry the responsibility to test every feature OpenAFS can perform, but rather only a vetted list of features which we choose to support. This is a practical matter, a plain fact. The cause of honest discussion is not advanced by this silly reductio ad absurdam. > >>> In order to add new ACL bit assignments to OpenAFS either the community >>> needs to revoke the availability of the site local bits or we need to >>> alter the protocol in order to support a larger number of bits. >> >> Or, the community could decide that the proposed approach is just fine. > > They could. We've heard from a number of voices against the proposal. It > would be interesting to hear from people who believe both that > integrating this patch is a good idea in theory, and who would in > practice use it at their site. You are arguing that there's no consensus > against this patch, and that may be true. However, there certainly seems > to be no consensus for including it at the moment. As argued above, this argument is not sufficiently persuasive nor sufficiently strong for its intended use (proscription). > > Cheers, > > Simon. > Regards, Matt - -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJPp2YJiSUUSaRdSURCJwFAKCS4R0itnCic76ywdoLRX60aoR5+wCgi4ZI ysgdbROVgejltPRJ9Ui4+Bs= =LdyD -----END PGP SIGNATURE----- _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
