--On Monday, December 08, 2008 08:17:23 AM -0500 Jeffrey Altman
<[EMAIL PROTECTED]> wrote:
Matt Benjamin wrote:
Although I follow this reasoning, I'd at least tender the possibility
that the following reasoning is at least equally plausible, disregarding
for the moment the current scarcity of ACL bits:
Unfortunately, the scarcity of ACL bits is one of the significant issues
associated with accepting this patch. If we had a bit that we could
assign to it, then we would accept the patch based upon the merits of
the functionality and the quality of the patch.
Matt very carefully tried to avoid the question of scarcity of ACL bits and
address the larger question of whether it is appropriate and useful for
OpenAFS to contain code that is useful to and enabled for some sites but
not all, or whether we will force anyone who wants a site-specific feature
to take on the burden of maintaining a local patchset and updating it for
each new version.
I know where I stand on that question. I maintained a fairly extensive set
of site-specific patches to AFS throughout most of the 1990's. One of the
first things we did when we started the OpenAFS project was to apply a
number of site-specific changes and other improvements that various sites
had collected over the years but which had never made it upstream. Life
had suddenly become a lot easier for many of us. I used to maintain around
20 site-specific patches for AFS. Today I maintain three:
- find compilers where we put them
- change how AFS_component_version_number is formatted
- support for a local ptserver extension involving a large hash table
of IP addresses, which I haven't figured out how to generalize
I don't want to go back to the old way, and I don't want to force others to
experience that pain, either.
Unfortunately, you've decided to ignore that question, and talk about the
scarcity of ACL bits. Fine.
The proposal was not to allocate a non-existant ACL bit. The proposal was
to add a feature which, if enabled, uses one of the site-specific ACL bits,
and to determine which bit to use at configure time. This puts the code in
OpenAFS, where it's easy to maintain, and the allocation of site-specific
ACL bits in the hands of server administrators, where it belongs.
Since such bits are not available, the questions then become "is this
functionality something that the vast majority of sites would want to
make use of?"
That doesn't follow. Sites that don't want this functionality don't have
to turn it on, and there's plenty of precedent for building in features
that most sites don't turn on.
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.
1. it is in fact reasonable for different access control policies to be
applied in clearly distinct administrative domains (the definition of an
AFS cell); Viewed in that way, it seems quite illogical to invoke "the
principle of least surprise" as an argument against site-specific ACL
behavior
It is perfectly reasonable for different cells to apply different
policies. It is not reasonable for different cells to use different
protocol semantics.
Nonsense. Different sites use different semantics in all sorts of
protocols, all the time. If that weren't the case, there would not be any
need for private-use values in protocol fields.
Changing the meaning of an ACL bit from one cell
to another is the equivalent of changing the protocol not to mention
the user interface.
Actually, it doesn't change the protocol at all. The protocol defines the
bits in question to have site-specific meaning; anyone who depends on their
semantics without knowledge of what they are being used for deserves what
they get.
It doesn't even change the user interface, 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.
A user or admin that works in two cells should not have to double check
every time they set an ACL how the ACL bits are interpreted in that
cell. It is fine for a cell to decide to activate or deactivate
particular bits, it is not fine for cell administrators to decide what
the meaning of a bit should be.
Too late; that ship has already sailed. The very existence of
site-specific ACL bits is a statement that it _is_ fine for cell
administators to decide what the meanings of those bits should be. That
decision was made, and the bits were being used, long before the OpenAFS
project was started.
In this regard the "site local ACL bits" are a usability nightmare
and in my opinion they should not be used at all UNLESS the cell is
operating in a private name space disconnected from the global AFS
name space.
Frankly, as a site administrator, I don't think your opinion is a viable
substitute for my reasoned analysis about what my requirements are and what
I need to do to satisfy them. If you don't want to take this patch because
you think it's too complicated or too hard to maintain or doesn't do what
is intended or is too marginal, say so. But you're saying you don't want
to take it because site administrators shouldn't be allowed to use bits set
aside for their use, and that's just silly.
That does not imply that the OpenAFS community encourages their use
nor does it imply that the OpenAFS distribution should make it easier
for cells to shoot themselves in the foot.
No, it doesn't. But the OpenAFS community is capable of making decisions
for itself. The topic of usability and management of site-specific ACL
bits is not one that the community has ever discussed, to my knowledge.
Please don't take your opinion on the topic and present it as the consensus
of the community.
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.
Adding a --enable-foo switch and a corresponding ENABLE_FOO preprocessor
macro does not increase complexity; it takes advantage of functionality
that is already there. We can have any number of such things without any
change in the complexity of the build system.
will not ease the
testing burden of organizations that wish to make use of those patches
unless the OpenAFS gatekeepers were willing to take on the
responsibility for testing those site local configuration options with
each release. Each new feature that is compile time configurable
requires a separate set of testing with that option turned on and off.
Adding multiple site local configuration options means that each
combination of option must be tested.
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.
The OpenAFS gatekeepers and the broader community are in no position
to perform such testing. As such I believe it would be irresponsible
to accept such patches into the source tree. Doing so would do nothing
more than (a) send the message that using the site local ACL bits is a
good idea
Again, that ship has sailed. You've said you think it is a bad idea for
sites to actually use site-specific bits, but I see nothing resembling a
community consensus behind that position. So, I fail to see the value in
an argument that something should not be done because it fails to send that
message.
and (b) send a message that the functionality is tested
when it is in fact not.
This, in fact, is the only meaningful argument you've made yet, and the
only one that actually addresses Matt's original post, instead of going off
onto the tangent of whether and how to assign site-specific ACL bits. I
think that's unfortunate, because the real issue here is not about ACL
bits; it's about the extent to which OpenAFS should accept and maintain
code that is not turned on in every build.
I think that is a fundamental question about the philosophy of the project,
on which we need to have a real community discussion, rather than having a
few individuals make decisions by fiat.
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.
-- Jeff
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
