On Thu, 26 Jan 2012 10:51:14 -0800 Russ Allbery <[email protected]> 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 [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
