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 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.
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.
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.
[...]
It doesn't even change the user interface,
Consider how this looks to a user. They don't go "I'm setting bit 'A',
which is a site-specific bit and I'm in cell X.COM, so that means
<blah>". They think "I'm setting bit 'A', which means <blah>, because
that's what it has meant every other time I've set it". AFS has enough
usability issues for users - let's not add new ones.
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.
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.
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.
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.
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.
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.
Cheers,
Simon.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
