Andrew Deason <[email protected]> writes: > Russ Allbery <[email protected]> wrote:
>> 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. I should also mention on this that we've not been making the problem clear enough (and I have now gone off and tried to start to remedy that). > 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. Oh! Yes, that was something different than what you were talking about. The basic problem that I have with structural changes to the server and client code to fix things like this is that I don't know the server code well enough to have an opinion. I don't participate in those discussions not because I'm not interested, but because I defer to the technical judgement of people like you, Jeff, Simon, Derrick, and jhutz on what the correct implementation is and what would be effective. The only general offering I have in evaluating those sorts of solutions is that they need really solid testing, and at this point the itch in the back of my brain says that the code is very fragile here. I'm not sure what the solution is to that fragility, but in other programming projects I'd be trying to add tons and tons of tests and then start refactoring to try to rebuild layering and cleaner internal organization. But this is just an intuitive feel. Part of the problem that I think we all have is that we don't know when the solution is working and how to tell that it's not broken something else. And to some extent this is just a hard problem: it's threaded software that's part of a distributed system, which is notoriously the worst possible case for effective debugging and analysis. > 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. Okay, yes, that makes sense. I'm not really trying to be dramatic here; I'm just frustrated. And not at you, particularly, but at the general community situation, the list of things that I know AFS needs to do in order to stay strategic, the difficulty in finding a funding model for that work that is actually effective and achieves its goals, and the amount of time that's taken away from strategic development to try to get OpenAFS 1.6 stable. And Elders issues that haven't resolved for 18 months, and... you know. It's a long list. > 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. Oh, yes, absolutely. I mean, it's not the only issue; the issues of how to change a protocol in a backward-compatible manner are also significant, as well as what we want out of the standardization process, and code complexity issues, and so forth. But, in general, if we're managing the complexity we already have, I'm more comfortable with adding more. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
