[OpenAFS-devel] Re: Breaking callbacks on unlink

[Andrew Deason]

On Thu, 26 Jan 2012 10:51:14 -0800
Russ Allbery <rra@stanford.edu> wrote:

> > or, something in that area. I've mentioned a few times a few
> > different changes that I think can alleviate some of this, but... I
> > never heard anything back about them, so it didn't seem like you
> > were interested or that it wasn't that important.
> 
> That's an unfortunate interpretation of delays in implementing
> configuration changes, and I'm sorry you got that impression.  A
> better conclusion to draw is that it takes quite a bit of time to
> implement file server configuration changes in a large environment
> with a zero scheduled downtime requirement.

We may be talking about different things. I mean things that afaik are
not planned to be implemented or even explored that were kind of
mentioned in passing. (lock quotas per-vnode, or per-volume, or per-host
but for i/o instead of net; not needing to lock the host for such a long
period of time on a new rxconn; possibly some others) I don't mean the
stuff you're implementing; I'm used to up to multi-month delays on that
kind of thing.

> However, because AFS is seen as less and less strategic at Stanford,
> in part because of ongoing reliability issues but more because the
> usage patterns of file systems have changed and OpenAFS is not
> currently keeping up, the amount of time that I have available to be a
> gatekeeper has diminished considerably.  If my remaining contribution
> in terms of trying to advocate for the sort of project I think OpenAFS
> should be is out of step with the community, then I can resign.

Whoa whoa, hey, no, I'm not saying that. I do not think any of this is
representative of you being out of step with the community; you are very
much in step with a large part of it. The viewpoint I'm trying to
represent I think just comes from a different part of the community; one
of the roles I/SNA try to serve on the lists is to provide a voice for
some of the sites that are unable to participate in discussions like
this themselves.

> > If you want to try to say that we shouldn't add anything more until
> > these problems are solved, then... well, I don't think you're trying
> > to advocate that everyone should stop what they're doing just to
> > help you :) but that at least puts a kind of limit on things.
> 
> There is, of course, an inherent conflict of interest in any
> gatekeeper position in that one is not going to care enough about AFS
> to become a gatekeeper unless one is actually using it, and the
> problems that one is personally running into are going to, shall we
> say, come readily to mind.  Part of my job as gatekeeper (and, more to
> the point, elder) is, somewhat inherently, to advocate for Stanford's
> issues and concerns and hope that those issues and concerns are at
> least somewhat representative of a class of users of OpenAFS.

I think you said this better than I could have. There is always going to
be some bias in this area, so for that I certainly do not fault you and
I think you do a great job of balancing that and not abusing the
position or anything like that.

So if such a vehement opposition to runtime options may lessen a little
if stability is improved... that's great and something to work towards,
and something I can completely understand. Before the emails today it
didn't really occur to me that that might have been contributing to such
an opinion.

-- 
Andrew Deason
adeason@sinenomine.net