On 9 Dec 2008, at 16:32, Matt Benjamin wrote:
In general, I am of the belief that prescriptive rules, here
specifically, the proscription sites _should not have_ site local ACL
bits,
I'm certainly not saying that sites _should not have_ site local ACL
bits. Sites are free to do whatever they like with the site local
bits. What I'm arguing is that OpenAFS should not ship with a
mechanism to allow sites to assign a meaning to an arbitrarily chosen
one of the site local bits by flipping a configuration flag, without
reconciling the security and usability issues that this presents.
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.
Is there merit in adding a new feature to OpenAFS simply because a
single site requires it, when that feature is implemented in such a
way as to impede the usability of OpenAFS as a whole? Surely the way
forwards here is to explore ways in which this feature can be
implemented so that it doesn't impact upon others. I suspect many
would find the feature itself useful, but would not be prepared to
accept the maintainance and usability burden it brings with it.
* 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
There's pretty strong evidence that as the number of configuration
knobs increases, the usability of a product decreases. The balance is
finding the _right_ number of configuration knobs such that it is
usable by all classes of users, from novice to experienced. You only
need to read IRC, or the openafs-info list, to realise that the
process of configuring OpenAFS is daunting for a novice user. If we
want to expand our userbase, we need to tackle this complexity. This
isn't to argue against OpenAFS being more things to more people, but I
would like to see the number of incompatible choices reduced, and more
code included by default in the stable builds (for example - why
should a new user have to decide whether or not they need this
'supergroups' thing? If it's stable it should be on by default, if
it's unstable, it shouldn't be in the stable tree). I realise that
we're not going to solve this problem in a day, but I think we have to
start thinking more about how simplify adoption for new sites.
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?
Your analogy is flawed. No matter how many notes Mozart used, it was
still possible to determine the quality of the resulting work.
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.
To be clear, I'm not attacking the addition of new features - I'm all
in favour of them! What I'm against is the addition of code
_particularly on the stable branch_ which is hidden behind arcane
combinations of build time configuration switches. (Run time
configuration switches are a slightly different matter). But the
configuration switch issue is really just a symptom of why this patch
is flawed, rather than the cause.
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.
Ok. So there's a major philosophical argument here. Why would OpenAFS
ship code that it doesn't support? If the code isn't supported at all,
doesn't it belong in some kind of 'contrib' area, rather than in the
main build. I think there's an assumption that everything in the
OpenAFS tarball is supported, as much as any of OpenAFS is supported.
As far as I'm aware, we're not currently listing a set of options that
gives you a supported build, and declaring 'here be dragons' for
everything else. However this is really beside the point - the patch
isn't flawed because it adds yet-another-configuration switch, but
because it does so without regards for the consequences of making this
option configurable.
But respectfully, we
have, collectively, a right to expect the solutions to be the best
available, to be sensible, flexible, and well reasoned.
My argument, as I've made before, is that the solution presented by
the patch we're currently discussing is neither sensible, flexible nor
the best available.
Let's consider the issues. The patch creates a compile time option
which allocates a user determined site-local ACL bit to have a
particular meaning. There is currently no way of guaranteeing that the
bit that's been selected is consistent between sites, or even between
file servers. This creates, as far as I can see, the following problems:
*) A user with a presence in multiple sites has to remember what each
site local bit means in each site. Forgetting this meaning may lead to
them setting permissions on their files which they didn't intend.
*) Systems staff building OpenAFS across a large environment must
ensure that every fileserver build has the same set of configuration
options. A failure to do so means that ACLs will silently change
meaning when a volume is moved between servers
*) Systems staff upgrading OpenAFS must ensure that the new build is
done with the same options as the last one. Failing to do so will
cause ACLs to silently change meaning upon upgrade.
In my opinion, an acceptable patch would have to address these 3
issues. I think it could do so by adding a mapping RPC, similar to
what Derrick has already discussed to solve the first issue, and by
having the ability to detect, and warn of, the latter 2 cases.
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.
I think any successful large project has to have a group of people who
take the broader view, and consider the impact across the entire
system of new features. Some features may be of use to a single user,
but damaging to the system as a whole. Part of the process is
balancing the needs of the one with the needs of the many, which
requires that, upon occasion, some modification of proposed new
features is required.
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.
I don't agree. You're suggesting a utopian scenario which doesn't
compare with many of the site realities I've seen. How many times do
we get messages from admins whose predecessors have installed an
ancient OpenAFS, and they're looking to upgrade, but don't know where
to begin? Building a successful product is about making it easier, not
harder, for the users who are least able to help themselves.
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.
I think your experience of the world has been a little more cosy than
mine. I can think of many sites that don't coordinate releases in this
way. They probably should, but they don't, and that's the world in
which we have to operate.
S.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
