[00:06:59] --- abo has become available [01:24:22] --- dev-zero@jabber.org has left [01:38:05] --- Russ has left: Disconnected [01:38:28] --- Russ has become available [03:00:28] --- Russ has left: Disconnected [03:02:48] --- SecureEndpoints has left: Replaced by new connection [03:02:51] --- sxw has left [03:04:06] --- sxw has become available [03:06:18] --- dev-zero@jabber.org has become available [03:58:47] --- dev-zero@jabber.org has left [04:37:03] --- dev-zero@jabber.org has become available [05:08:11] --- dragos.tatulea has become available [06:30:24] --- dragos.tatulea has left [06:33:23] --- Derrick Brashear has left [06:41:03] --- SecureEndpoints has become available [06:58:41] --- mcohan has become available [07:02:49] --- SecureEndpoints has left [07:03:43] --- Derrick Brashear has become available [07:09:40] steven, klog.krb5 link issue fixed in cvs last night fwiw [07:12:13] shadow: Do you have any thoughts on the dentry_iput issue? [07:12:38] not yet. i read your exchange with chas, though, which helped me understand what the issue we're talking about is [07:13:26] Yeh. I don't think it's a huge issue when we're _not_ disconnected, as whilst the file is open the dentry will be referenced enough that it shouldn't get flushed. [07:13:35] (There might be a problem with background writes to slow servers) [07:16:23] shadow - saw the klog commit; tx. [07:18:09] Hmm. The problem is that the dentry can hit 0, whilst we've still got 2 references on the inode. [07:18:25] ok [07:19:07] (One of those is our vlruq, the other is the one we get rid of at the end of dentry_iput) [07:19:52] lemme deal with the person on irc who's asking about a client issue, if i can, and then i will read code [07:20:33] --- matt has become available [07:21:23] --- reuteras has left [07:22:13] --- reuteras has become available [07:27:18] he disappeared. let me look at your issue now [07:28:12] Okay. It's definitely an issue for disconnected, I'm not sure how much of an issue it is in normal operation. [07:28:13] just from a first pass at the code i think chas is confused. let me reread what he suggested [07:32:51] --- dmontuori has become available [07:47:38] shadow & secureendpoints, wrt wdelta/volser-setflags-clear-callptr-20090118 & rx calls in general, why does rxCallPtr need to be reset? Is that to designate that this is the final operation in the chain of calls? [07:50:57] if it's not cleared it signals an error. that function sets it, that function cleans it up [07:51:04] same as it did in 1.4 [07:51:18] it's not necessarily therfinal operation [07:51:24] it's just "that's how it works" [07:51:36] you set it, you clear it [07:52:08] got it, tx. [07:55:29] btw, wrt 'bugs in DAFS that are known but not public', just got the rest of the approvals needed to share the bug reports, so there's a process in place to get sync'ed into rt.central.org now. [07:56:55] > You can't go easily from a vcache to the path it comes from Depends on the platform. You can certainly easily go from a vcache to a vfs inode, and on some platforms, turning that into a path is fairly trivial [07:57:22] stevenjenkins: In general (and not restricted to the DAFS case), I feel it would be good if we could have a system where actual software bugs (rather than customer issues) could be tracked in one location. It would make knowing what issues exist, and whose working on them across the entire community much easier. [07:57:29] ok [07:57:44] sxw - agreed. [07:58:11] right on [07:58:20] ok, after reading kernel and openafs, i am pretty sure chas is wrong [07:59:12] From what I've done, I think the missing link is that there's a different between the dentry reference count hitting zero, and the inode reference count doing so. [07:59:37] --- reuteras has left [08:01:23] ok [08:18:47] --- mcohan has left [08:19:22] --- mcohan has become available [09:02:30] For those interested in extended callback information, I've been giving thought to better tuning of workload obligations. In traditional AFS-3, callback notification always breaks the server's callback promise to the client. In xcb, we say that it persists by default, but the server may break it with the notification. This is sufficient to allow a fileserver to adapt to changing workloads, but it's not optimal, because the client is in a better position to know its level of interest in particular objects than is the fileserver. Consider that some set of objects in, but idle in, one clients cache may become the subject of contention by some other group of clients. Persisting the callback promise on those objects at the idle client appears to increase protocol and server workload, without corresponding benefit to users at that client. Correspondingly, perhaps we should suggest that client implementations give up callback promises (RXAFS_GiveUpCallBacks) on receipt of notifications on objects they have reason to believe are not of immediate interest. They would be encouraged, I think, to make use of the information provided, then give up the promise only, unless otherwise motivated to discard from cache. [09:02:37] This is distinguished from clients simply discarding callback promises periodically, by virtue of clients' awareness that discarding promise on these objects specifically is likely to reduce workload. [09:04:00] there's no reason not to apply the information, then GiveUpCallbacks, since if they become interested again they just need to (potentially) reverify they're up to date, and fetch nothing [09:04:07] That seems reasonable. It seems more like an implementation detail (clients can already give up callbacks that no longer interest them), rather than a protocol issue, though? [09:04:26] that said, the client could stand to be more aggressive about giving back callbacks, i suspect, though i can't immediately suggest when [09:04:57] sxw: not completely, but yes, a suggestion for implementation [09:05:14] There are others readers have requested to appear in the draft. [09:06:41] There do seem to be protocol implications in this case. [09:07:48] Does the client not always have the ability to discard callbacks they no longer care about? [09:08:40] It does--but the former protocol makes it unlikely that it will be inclined to do so, except in exceptional circumstances. [09:09:17] --- dev-zero@jabber.org has left [09:09:22] Yes. Extended callbacks make it more likely, because the client can now go "Why are you telling me this, I don't care" [09:27:56] I have an experimental, please-please-don't-take-my-head-off file locking patch for Windows clients. [09:31:34] > For those interested in extended callback information Dude, some line breaks would be nice [09:31:47] Sorry, jeff [09:32:50] jeff's at the hospital now, i think, so he'll not be reviewing it. i'd be happy to look [09:33:02] Is he ok? [09:33:26] yes [09:35:15] Minimally, it appears valuable for my particular style of power usage, which includes making extensive use of cygwin applications, and also ansi/portable programs which use open, fopen, and shared versions of these, which ultimately call CreateFile. [09:36:57] i parsed that as meaning, like, battery or wall AC power. [09:36:59] but, got it [09:37:34] Me too, I started thinking of some kind of low-energy AFS ... :) [09:38:35] As currently implemented, any file opened using this path necessarily causes the cache manager to take a Read lock--this meets one definition of required Windows semantics, the DOS subset, basically. Meanwhile, MS office applications will open a file in shared mode, then take a byte range lock on a region of the file, which itself our client promotes to server locks of an appropriate type, so there is protocol overlap. [09:39:40] so what's the patch do? [09:39:46] My patch creates a mode in which the file server (smb or redirector) will take account of the share mode in the open, and if it is share-read or share-write, omits to take a lock at the server. [09:39:50] someone's killing interactive performance here. sigh. [09:39:53] (registry controlled) [09:40:32] It does not alter the byte-range locking behavior. [09:42:04] As an example of the different behaviors, currently, to traverse a directory of n file objects, Cygwin GNU find indirectly takes...2*n file locks. With patch, it takes 0. But MS Office application sharing behavior is uneffected. [09:43:29] (ie, with patch in relaxed-shared-open mode) [09:43:29] the question in my mind is for how many people would the behavior from the tweak be correct, since, well, it seems odd. [09:44:13] I think it's a valid interpretation. Note, it correctly enforces exclusive open at the server. [09:44:23] sure, i got that [09:44:50] > low-energy AFS That'd be nice. For example, we could stop touching the CacheItems file every second. [09:45:05] didn't you already do some work in that vein, jhutz? [09:45:22] I looked at it. I don't remember if I ever actually did a working patch. [09:45:44] gnu find taking file locks proportionate to its traversal is odd too [09:45:50] Oh well, disconnected will just give you a load more files you touch on a regular basis. [09:46:36] it depends in what mode you're using find, i'd argue [09:46:57] I _suspect_ the tweak is valid for folks using shared semantics for a large class of modern applications, and few or no very old ones, with shared semantics. [09:47:03] But I'm not certain. [09:47:31] That class includes all ansi/portable applications. [09:47:41] --- stevenjenkins has left [09:47:42] As well as MS office and similar, as noted. [09:48:05] given that it's turned off by default, i assume, the only question in my mind would be that of code/registry bloat, i think, at least as long as it doesn't in some way tell you you have a lock and then let you screw yourself. [09:48:29] Agreed. Patch is extremely small. [09:48:53] --- mcohan has left [09:49:03] It clearly hasn't told you you have a lock--you had to explicitly request sharing. [09:49:23] so not even code bloat, just registry bloat/potential for confusion, which is probably a nonissue [09:49:35] --- mcohan has become available [09:50:00] --- abo has left [09:50:23] --- abo has become available [09:50:54] --- stevenjenkins has become available [09:51:35] Requesting sharing doesn't mean I'm not then going to take a lock. If I request sharing, then take a lock which should have been translated to a whole-file lock on the server, it had better still take effect. [09:51:57] The problem is, I cannot not-take a lock. [09:52:04] With those semantics. [09:52:23] I may do so only if I use memory-mapped io, I believe. [09:52:33] --- dmontuori has left [09:52:39] --- dmontuori has become available [09:54:52] The option to take a shared, whole-file lock is provided, via LockFileEx [09:55:02] --- dmontuori has left [09:55:26] --- dmontuori has become available [10:01:07] You mean, if the semantics require locking to work, then you have to take a lock? Well, yeah. Not much you can do about that. [10:01:22] Fast is nice. Fast and racy is bad. [10:01:44] agreed [10:02:34] Yes, but again, for the workload for which this is intended, there is no racing. [10:02:56] More generally, I think it is important for us to behave correctly in _all_ cases, not only in those cases where doing so is convenient and doesn't slow things down too much. Otherwise users cannot count on our behaving correctly, because they won't be able to predict when we do and when we don't, and at that point, we may as well not have locking at all. [10:03:19] The client provides an option to turn off server lock promotion, if you wish to race. [10:03:35] We must behave correctly according to the published semantics of the interfaces which we implement, not according to how we think people should use those interfaces. [10:04:46] I'd be worried about such an option, because pretty soon the users will be telling each other "if you want it to go faster, set this option", and people will start doing so without understanding what it really does, and then wonder (and submit bug reports) when their software breaks. [10:05:08] They could do that now, with EnableServerLocks. [10:06:06] of course today server locks aren't very strong. i could make them go away: just send unlocks until the file is unlocked. [10:06:40] Yes. That is known. I have suggested we efficiently implement server-coordinated byte range locks, which do not have that property. [10:10:24] yeah, i know. it just needs to get done. i am not casting aspersions based on the fact it hasn't. it just hasn't yet [10:13:00] I am presuming, I think credibly, that even though the semantics of Windows programming interfaces are known, and those of CIFS are known, that the specific mapping of our protocol semantics to those of the programming interfaces is one left in part for us to define. I have adduced two additional factors, which seem to support the claim that semantics more like the ones I propose, are becoming more standard usage, inside and outside Microsoft. That claim is certainly not the strongest I've ever made. [10:14:24] I have provided a detailed design proposal, so though it's not done, real work has been done. And, with assistance of various kinds, I have implemented extended callback information, which I believe permits efficient implementation of byte-range locking protocols, without polling. [10:15:24] "becoming more standard" leaves wiggle room. the problem is who do things already work for that potentially become roadkill, de facto or because you gave them a remote control car and let them run themselves over [10:16:16] I've admitted it, there's wiggle room. I propose experimental status. I take jhutz's point, but I don't think we need to take responsibility for all foot-shooting users want to attempt. [10:17:36] my problem is i want a chart to help me understand all the cases which are possible. there are too many. [10:17:55] at this time i would categorize my position as "cautiously interested" [10:18:12] I think it does need a chart. I think cautious interest is a reasonable position. [10:32:53] --- Derrick Brashear has left [10:34:39] Basically, the deal is this. The APi documentation says "if you do foo, then bar will happen". It is then our responsibility to make sure the statement is true. We do not get to rewrite the statement. We do not get to add "unless the file happens to be in AFS, in which case something completely different happens". [10:36:12] When using ansi/portable applications, it's the user who does not get the behavior s/he specified. [10:37:45] I'm not sure what you mean by "ansi/portable", here. Are you saying that the C standard library interfaces don't behave according to the standard? Are you saying that the POSIX interfaces don't behave according to the standard? [10:41:01] the API documentation, incidentally has apparently been provably wrong in the past, so i don't take it as set in stone. it's subject to sanity checking. [10:42:39] Oh, certainly. But not to our unilateral interpretation. [10:46:42] FWIW, I would not object to a patch that produces an incremental improvement, such as getting better performance without breaking any situations in which we already behave correctly, even if it did not fix cases where we are already broken. [10:46:51] /interpretation/re-interpretation/ [10:49:09] i agree with that sentiment unilaterally :) [10:49:54] --- sxw has left [10:56:24] Are you saying that the POSIX interfaces don't behave according to the standard?> I think I am, yes [10:57:19] I think we've done what we can at this juncture, I'll post what I have, and we'll see what happens [10:57:42] ok. [10:58:42] (but I haven't actually read the POSIX recently, I will review the applicable assertions before raising this topic for further discussion) [11:32:20] --- sxw has become available [11:53:31] --- Russ has become available [11:59:44] --- edgester has become available [12:28:45] --- dmontuori has left [12:39:45] does the latest krenew have an option to not die if the ticket/token renewal fails for some odd reason? [12:43:05] No, I'd not realized there was a need. Are you running into a case where you're seeing transient failures killing it? [12:43:42] possibly [12:43:52] there's also the case of if the tickets expire, then krenew fails, of course, and it dies [12:44:08] which means if someone then re-kinits, there is no running krenew to keep going [12:44:29] Yeah, but in that case I think that behavior is correct, since there's nothing krenew can do with the expired ticket cache. If someone re-kinits, they can respawn a new krenew at that point, since there's an interaction point there. [12:45:12] well... it's one more step for the user... I'd prefer to keep the magic of krenew (and users having to distinguish between lifetime and renew lifetimes/etc) hidden [12:45:21] an option to not have it die when tickets expire would be nice [12:45:32] Sure, that makes sense, but I'd do that by just wrappering kinit with something that spawns krenew for them. [12:45:51] one could wrap it, but that's much uglier [12:45:59] What's starting krenew in this environment? [12:46:23] in my case, one of the gdm startup scripts or the csh.login, depending on if it's a console login or an ssh login [12:46:35] Ah, okay. I think I get it. [12:47:10] Okay, I'll add that to the next version. [12:47:16] awesomeness [12:47:35] btw, you should have a paypal donation link or some such thing up [12:48:24] --- abo has left [12:48:25] --- stevenjenkins has left [12:49:05] --- abo has become available [12:50:38] I actually don't somewhat intentionally for a few reasons. Stanford pays me to work on a lot of this stuff, so having people pay me more feels weird, Also, money creates a sense of obligation for me even if people don't intend it that way, which means extra stress. And, really, I have enough money to be able to have most things I want out of life. [12:51:00] Maybe I should add a note that says that if you want to contribute something, give a few bucks to one of the charities at http://www.eyrie.org/~eagle/links/charities.html [12:51:42] --- stevenjenkins has become available [12:53:29] Russ: What about directing people to donate to openafs? [12:55:01] It's not listed there at the moment because we don't really have a good place for people to donate *to*. [12:56:14] * Russ looks at that page and should update it. Amnesty International, although I still believe in their goals, has a horrible fundraising to program funding ratio. [12:57:58] hm. an openafs ngo... [13:39:38] --- mmeffie has become available [13:40:54] Well, I can now build OpenAFS whilst disconnected, right until the point we start building the Linux kernel and make a symlink (which isn't supported) Believe it or not, this is serious progress ... [13:41:06] yay! [13:43:14] wow. [13:43:20] that's pretty exciting [13:45:43] This is just Linux. I think each platform we want to support disconnection on is going to require a level of individual work. [13:47:05] probably. it will help us work out vm syste bugs, tho [13:47:16] actually, yes [13:50:12] Can't resync though .... hmmm ... [13:50:44] --- manfred has become available [14:13:36] Thanks for the RT close, Derrick. Forgot about that. [14:14:04] de nada [14:29:21] --- manfred has left [15:04:34] This will all be so much faster with Git. [15:05:05] Oh yes. [15:06:31] * Russ probably doesn't do some AFS work right now just because committing and pulling up is a chore. Slightly smarter scripts would make it less of a chore, but hacking on CVS is so unrewarding. [15:06:50] I think gerrit will solve your pull up problems. [15:07:10] That sounded interesting. I was wondering how we were going to address that, given that commits get different IDs on cherry-pick. [15:07:25] The gerrit workflow should make it much easier to submit, review and apply patches. [15:07:35] I'm going to have to look at gerrit for managing our Puppet repository. My current proposal should work, but it relies on doing a lot of git merge -s ours. [15:08:26] Basically with gerrit, you use a wrapper tool 'repo' to manage your local repository - that pushes changes you want to upload into a specific branch of the upstream repository which gerrit then manages. [15:09:31] Where's the documentation for gerrit? [15:10:22] http://source.android.com/download/using-repo talks about it a little. [15:11:27] http://source.android.com/submit-patches is perhaps a better overview, though. [15:14:00] Hm, I don't see anything in there about how pullups are handled, which is the thing I'm the most concerned with. Does gerrit deal with that? [15:14:38] What's there seems like just a webified version of git format-patch / git am, which is useful but not horribly exciting. [15:15:24] It doesn't (currently) handle commits to multiple branches. I think the Android model for that is that a contributor who wants to commit to multiple branches provides a patch for each branch. [15:16:10] The big win with gerrit is that it makes review really easy. So you can get more eyeballs onto patches, quicker. [15:17:19] Ah, hm. Okay, that's not solving my problem. It's solving an interesting problem, and we should probably use it, but it doesn't really help with what I'm trying to do. [15:17:29] What I want is git cherry-pick with history. [15:17:39] Ah. Okay. Different problem, indeed. [15:18:04] I want to be able to pull arbitrary commits from master into branches and then be able to run a command that tells me which commits I've *not* cherry-picked (actually, which commits *anyone* has not cherry-picked; local state won't help). [15:18:43] It's probably immediately obvious to anyone who's used the current delta system why I want this. [15:19:44] I can completely see why you want that. [15:20:41] Oh, hm, git cherry-pick -x probably gets me far enough that I could script this. [15:21:01] Provided that I can find a merge point so that I know when to stop searching backwards. [15:21:54] * Russ is going to need to learn how to use Git plumbing at some point. [15:23:20] So, you know that wdelta can do that, right? [15:23:24] Yeah, so if we always use git cherry-pick -x to do pullups, then I need to find the last merge point between master and the release branch, run git log back to the merge point in the release branch and collect all commit IDs that have been cherry-picked, and then get a list of commits on the master back to the merge point, exclude the ones that have been cherry-picked, and run git log on the rest. [15:23:28] rt: could someone dispose of 18206? [15:24:24] jhutz: Yeah, the problem at the moment is that CVS is painfully slow, so I want to go to Git, but Git isn't as good about pullups, so I need a Git-aware pullup mechanism. Sorry, I left out the middle part of that train of thought. [15:25:50] Russ: Is this for OpenAFS, or for your local puppet repository that you mentioned earlier? [15:26:23] Both -- they have basically identical problems. [15:26:50] Any project that maintains multiple branches that get most, but not all, of the same commits would have similar problems, I think. [15:27:45] Are our commits that similar, though? The same code for 1.5.x and 1.4.x, for example, is starting to look pretty different. [15:27:59] ouch [15:28:23] sxw: I don't care about the contents of the patch, just about the commit. In current parlance, the delta. [15:28:46] Ah - okay. I think I see now. [15:28:50] I want to know that the same delta has been applied to both branches, and hence the same problem fixed in both places, even if it was done completely differently. [15:28:57] Okay. Sure. [15:29:25] We need to avoid the problem of HEAD becoming a graveyard into which fixes go to die. :) [15:29:41] I think you avoid that problem by not having HEAD. [15:29:58] You can't really not have HEAD. There has to be some place patches go by default. [15:30:18] Yeh, but you really want that to be somewhere that there are at least some people building and testing. [15:30:22] We could make HEAD and 1.5 the same thing, which I'd like to do, and have only HEAD and the current stable branch, but you still do get the same problem since a lot of our fixes should go into the current stable. [15:30:34] I think that would be good. [15:30:39] It's still a lot simpler than today. [15:30:45] (Well, I'd like HEAD and 1.5 to be the same thing in an abstract sense that may not apply to 1.5 as it currently stands.) [15:31:02] 1.5 is what it is for somewhat weird reasons that hopefully won't continue to apply once 1.5 is released as the new stable. [15:31:13] But I do tend to think that the revision control system is the wrong place to solve this problem. Isn't checking that fixes go everywhere what a good bug tracking system is for? [15:31:21] Basically, I'd like 1.7 to be developed on HEAD. Fixing this for 1.5/1.6 isn't really worth it. [15:31:36] --- abo has left [15:31:37] --- mcohan has left [15:31:48] --- abo has become available [15:31:58] sxw: The bug tracking system needs to get that information from the revision control system, I think. [15:32:27] You can do that by opening a bug for every commit and then checking bug closers in changelog entries, but I find opening a bug for every commit to be fairly annoying unless the bug tracking system is at least an order of magnitude lighter weight than RT. [15:32:35] --- mcohan has become available [15:32:50] bug/commit works well for Mozilla. [15:33:13] Mozilla has like 30 times more manpower than we do, though. [15:33:41] Now, yes. Not so much post-Netscape, pre-Foundation. [15:33:42] --- stevenjenkins has left [15:33:56] (Really, what I want is Bugs Everywhere, which I think is really the future of bug tracking systems in Git.) [15:34:34] Yeah, but Mozilla always ran their project as if they had commercial software company levels of resources. They have as formal of a review process as GCC, for instance. I don't think we're going to have the manpower to do that, although maybe I'm wrong. [15:35:18] Well, the Mozilla review process isn't always as formal as it seems. Depends on the proximity to the release, and the severity of the change. [15:35:20] Unfortunately, Bugs Everywhere seems to be rather, uh, dead. [15:35:55] But, I would really like to see the opportunity for getting a second set of eyeballs on changes before they go into the tree. At the moment, nothing we have helps with that at all. [15:37:15] Yeah, I think we should definitely do gerrit. [15:37:19] --- stevenjenkins has become available [15:37:38] I could be convinced that a bug for every commit wasn't too bad. [15:37:50] I worked in a CodeStriker process for more than a year. It was very productive. [15:38:06] What I'd want is to be able to close bugs via commit messages without having to touch the web and have opening a bug (which can be via the web) take less than 30 seconds. [15:38:13] I don't think that's an unreasonable expectation. [15:38:16] I think we'd need to consider how we interact with our BTS before code/commit worked for us. [15:38:41] * Russ really wants to get all ticket mail in e-mail, too. [15:38:41] And,I think both of your requirements would be essential. [15:38:48] Indeed. [15:39:10] I got some of that turned on for me in RT, so at least I now get told when a bug gets assigned to me. [15:39:24] Our current e-mail-centric implementation of RT bugs me. I live in my mail client, not in my web browser. [15:39:52] I don't think this is really an RT thing so much as a configuration thing and we could probably come up with a different configuration, although spam is going to be a big problem. [15:40:40] * Russ *really* wants a light-weight Git-aware BTS. [15:40:47] Yes. You can only really remove the spam problem by not letting anyone open a bug by email [15:40:54] I should probably look at redmine. [15:41:20] Yeah, for INN we closed the BTS to anyone other than developers. Which makes it annoying since the developers have to open all the bugs, but it gets rid of all the spam. That tradeoff wouldn't work for OpenAFS. [15:41:33] When we were discussing 1.6 a couple of days ago, tools came up. I think we should have a serious tools/workflow discussion, but only once we've got 1.6 out of the door. [15:41:39] Yeah, agreed. [15:41:45] I wonder if we could huddle at the workshop about it. [15:42:11] Closing the BTS via e-mail isn't enough, btw; you also have to disable account self-creation. [15:42:20] The web spammers these days know how to create their own accounts to spam with. [15:42:50] --- abo has left [15:42:55] * Russ really wants a light-weight Git-aware BTS for all my other projects too. I should probably look at Redmine. [15:43:04] I could use Trac, I guess, although its Git support is apparently not great. [15:43:23] --- abo has become available [15:43:28] Sorry; skipped too much. Huddle about what? [15:43:47] Better tools, improvements to workflow. [15:44:16] > Our current e-mail-centric implementation of RT bugs me. > I live in my mail client, not in my web browser. Uh, internal consistency problem here? [15:45:00] Er, sorry. Our current web-centric implementation. [15:45:18] The two sentences merged together in an unfortunate way. [15:47:41] I don't know how to do anything about that. You can submit tickets via email. You can reply to or comment on tickets via email. You can get notification of changes via email. There is no non-web interface for doing anything else. [15:48:33] Closing tickets automatically via commits and getting all traffic to all bugs sent to a mailing list are the two main things that I miss compared to other projects whose BTS I follow. The latter of course has problems with spam. [15:49:11] Right now, I end up going into the web to see new bugs and to close bugs. [15:49:46] I've never tried to use it at the right level, but sympa has cert/mime based mechanisms to attempt to address the spam problem. [15:50:46] But even if all the current bug traffic, including all the spam, went to a mailing list, I could at least run that traffic through bogofilter and get a fairly reasonable feed of new bugs and bug updates. [15:50:54] I could easily cause you to get mail with each new bug. But the spam problem would kill you, I think. I keep wanting to stick a mailman list in front of the ticket submission address, so that new tickets require moderator approval if they're not from a previously approved sender. [15:51:40] Yeah, the Mailman method sounds like basically a lightweight way for maintainers to create "accounts" for people authorized to submit bugs, without throwing away bugs from unauthorized people and without making people create accounts. I really ilke that idea. [15:52:13] And actually, if you can easily do it, I'd love to get email for each new bug and ideally every update to every bug as well. I can deal with the spam by filtering it out locally until we have something better. [15:52:31] I get upwards of 1000 spam messages a day anyway; I don't think the OpenAFS bug queue will make it that much noticably worse. [15:53:11] Could you use a sender driven whitelist? You know, one of the ones where you get an email back saying "If you really wanted to talk to me, please reply to this email"? [15:54:01] I'm just thinking of something that adds no extra workload - you get the bug submitter to do the work. [15:55:53] I really hate those things, because they are founded on the presumption that your desire not to get spam means that I should do extra work. [15:56:30] But I think in front of a bug submission address, they're more legitimate. [15:56:30] --- dmontuori has become available [15:56:45] I don't. Do we want to get bug reports? [15:56:48] It's sucky for personal e-mail, but for bug submissions, I can see the point. It's no more work than requiring people to create an account before using a BTS, which is not uncommon. [15:57:11] We want to distribute the workload. We don't have enough hours - the more we can ask users to do the better. [15:57:23] Basically, other projects do it -- if we don't, I think that's good for us, and certainly it's friendlier to not do so (provided you don't accidentally throw out the bug with the spam). But I'm not sure we have the resources. [15:57:33] I don't like requiring people to create an account, either, for similar reasons. And I know there are cases where I have just not bothered to submit a bug, rather than screw around with creating yet another one-time-use account in yet another web service. [15:57:58] Yeah, me too. [16:03:09] ietf folk: can one sugest an rfc with wire protocol features, that is a particular model to emulate? [16:03:25] (some-one) [16:04:47] I always found the SSH protocol descriptions pretty easy to follow - but that rapidly moves away from wire descriptions to higher level constructs. [16:08:25] thanks [16:08:52] Are you asking for a protocol to emulate, or a document to emulate? Are you talking specifically about a fairly raw bits-on-the-wire protocol, or something RPC-based? [16:09:39] I meant to say, document to emulate, yes; in this case, yes, bits-on-the wire [16:10:32] If the latter, you could look at NFSv4, which is RPC-based, but also over 600 pages long. [16:10:45] indeed, that is very large; i found it muddled [16:10:59] it probably exceeded me [16:11:30] but nfs rpcs probably fit [16:11:36] sorry, rfcs [16:11:58] --- mdionne has become available [16:12:36] Russ, what email address do you want to get all the openafs-bugs traffic? [16:13:00] rra@stanford.edu [16:14:17] OK, you asked for it. rra is now an admincc on openafs-bugs [16:14:21] Thank you! [16:15:16] That will get you ticket creation, correspondence, and comments. Currently not other state changes, unless you happen to be the owner. [16:15:44] That should be fairly good, though. Thank you so much. [16:16:23] no problem; it takes something like 2 seconds. less time than it took me to finally sign a GCO client cert for my desktop. [16:17:06] Hmmm. This sucks. ioctl() on Linux times out if you take too long to respond. Like, if you're flushing an entire OpenAFS tree up to a fileserver whilst reconnecting. [16:17:16] (which is easier than logging in with a password especially for mailman administration, so my browser is set up to use :444 on all openafs stuff) [16:17:27] huh? [16:17:45] exactly how does that work when you're seeking through a tape? [16:18:28] I have no idea, but I'm getting connection timed out, and it's not coming from AFS. About to read some glibc source, and then some kernel source. [16:23:02] --- matt has left [17:11:38] --- mdionne has left [17:16:13] --- edgester has left: Replaced by new connection [17:16:13] --- edgester has become available [17:20:58] --- SecureEndpoints has become available [17:28:41] Bingo. Solved it. It's a network error that's being stuck in by afs_CheckCode when the pioctl returns. d'Oh. I'm obviously too tired to keep staring at this now ... [17:33:40] FYI. rename-residency-from-mrafs-to-osd-20090119 breaks 1.5 [17:34:01] looks like there is some reference to ResidencyCmd that was not replaced [17:38:13] libafsrpc/afsrpc.def is still exporting RXAFS_ResidencyCmd [17:41:22] I do have to question why DELTA rename-residency-from-mrafs-to-osd-20090119 was applied. Did we really need to rename this functionality? This change is going to alter the exported function names. [17:45:32] secureendpoints - sorry about that; I tested 1.5 build, but only have easy access to Linux of various flavors. [17:46:11] I'm sure it would be ok to add RPCs instead of change them, but it seems most straightforward to do a rename, since that's how Rx OSD was done. [17:47:24] wrt breaking the windows build, that really stinks, and I'd like to avoid breaking it going forward. Can you point me to the 'how to build on Windows docs', and I'll see what I can get going? [17:50:32] the docs are in the top level of the repository [17:50:42] however, I am opposed to the rename on several levels [17:52:56] First, pioctls should not be renamed after assignment. If the functionality is the same, then the exports should remain constant so that applications that make use of the functions will continue to work against the new implementation. If the functionality is going to evolve into something incompatible with the old functionality, then new pioctls must be issued anyway to ensure interop safety. [17:54:04] Second, changing the names alter the export lists of the AFS libraries. Doing so will break applications that are linked against older versions of the libraries where the function export index and the exported function name no longer match the linked version. [17:54:49] I'll wait until you finish your list before responding. so let me know once your list is complete. [17:55:01] If we are removing the old functionality and replacing it with new functionality. The old function names should remain and be turned into stubs that return an appopriate error code and the new functions should be added to the export list. [17:55:08] done [17:56:23] ok. [17:58:08] first, I'm fine however we want to do this (rename vs new pioctls, etc). The rename was requested as that is how Rx OSD actually implements it, and a key point is that MR AFS is no longer around, so there should probably be a process for either declaring something defunct (I like your suggestion about stubbing it out to return an appropriate error code, although I haven't thought through how that would work), or there should be a process for re-assigning. [17:58:55] wrt old vs new functionality: Rx OSD adds functionality that MR AFS didn't have. [17:59:17] wrt your second point: changing names breaks AFS libraries. Hmm. Good point. [17:59:19] with network protocols you cannot re-assign because you can never be sure that all clients implementing the old version are gone [17:59:32] well, with MR AFS, we can, though.. [17:59:39] at least, that's what I've been informed. [17:59:47] Breaking the AFS libraries wouldn't matter as much of we were tracking SONAMEs properly on UNIX (and the equivalent on Windows), but we're really bad at this right now. [17:59:47] you can be sure that the servers are gone [18:00:28] you cannot be sure that the clients are gone because the clients are perfectly happy with speaking to plain AFS servers [18:01:02] MR AFS clients were proprietary only..and they're gone now. [18:01:07] One method a client uses for testing whether the server supports functionality is to call the RPC and test to see if the error code is UNSUPPORTED [18:01:24] I thought there were several sites that had MR-AFS licenses and redistributed those clients to their users. [18:01:56] I'm speaking second-hand wrt MR AFS status based on statements made at OpenAFS workshops & mailing lists, so I'm not authoritative on this. [18:02:25] if we would prefer to add new pioctls for Rx OSD, I'm totally fine w/that. [18:02:35] we should add new pioctls. [18:02:46] and the patch that was applied today should be rolled back [18:03:12] --- dmontuori has left [18:03:18] --- dmontuori has become available [18:03:24] --- dmontuori has left [18:03:36] --- mcohan has left [18:03:51] --- mcohan has become available [18:04:14] somewhat side question: wrt building Windows OpenAFS -- is Vista ok for a dev platform? I see various other OS'es specifically listed (2000, XP, and 2003), but not Vista. [18:04:49] you can use vista [18:05:00] you can use any OS as the dev platform [18:05:16] nothing from the build OS ends up in the output [18:05:58] tx. [18:06:24] if someone (e.g., registrar) wants to let me know the new pioctls to use, I'll be happy to re-submit a new set of patches. [18:06:37] in some ways though I am glad that changes like this end up breaking Windows because I don't want subtle changes like this to slip through without the necessary review [18:06:57] submit a request to the registrar for new pioctls [18:08:06] ok. I'll amend my previous request to them. [18:08:09] and once a request is in the RT you can bug jhutz to respond to the request [18:08:49] should I cc gatekeepers on this? [18:09:35] (I have no idea where mail to registrar@grand.central.org goes -- I thought jhutz + kula are the only recipients) [18:09:54] its not a gatekeeper issue. the community wanted the gatekeepers separated from the protocol standardization process. the registrars have to take care of their responsibilities [18:10:29] so if the registars are ok w/the rename, then ?? [18:11:00] if they issue the rename I will object to it [18:11:10] I doubt jhutz would [18:11:29] he has too much experience in the ietf dealing with the side effects [18:12:18] the rename has been in their queue for ~1 wk at this point..your objection is the first I've heard. And I had the same take wrt jhutz raising a concern if one was warrented. [18:12:30] err, warranted. [18:13:00] no registrar has responded to you. why do you believe the request has even been read? [18:13:34] one week is not a very long time. [18:14:36] I suggest that a few days would be sufficient for at least notifying someone that their request has been received. [18:14:39] and given the registrars jobs, this time of year is a very busy one [18:15:08] this is an all volunteer effort. people respond when their jobs and personal lives permit [18:16:24] I get the volunteer aspect. Some of my assumption is based on getting feedback on other items that were between that submission and today. [18:17:17] silence is not a positive response [18:17:29] * stevenjenkins nods. [18:17:58] silence means that either no one is interested in what you are proposing; no one believes they are competent to respond; or they don't have time [18:18:07] or that no one saw the request. [18:18:31] registrar requests do not go to the gatekeepers. I could not respond [18:19:16] Your submission of 124130 was today. There was no time to respond to it before the code was committed. [18:20:18] um, no. That was 1/14. [18:22:31] In any case, the next step is for me to ping registars and ask for *new* numbers, not a rename. Once that's done, I'll update 124130 and re-submit. Correct? [18:22:40] ah yes. and Simon raised my concern on the 15th [18:22:48] correct [18:22:56] in the meantime I'm going to pull the patch [18:23:04] there was some discussion about it, yes. [18:24:18] pulling the patch seems reasonable to me. my main concern is registrar<->gatekeeper communication/coordination (with developer being the 3rd part of that triangle). [18:25:04] wrt this issue, I'll handle it by not submitting a patch until the registrar's have signed off. [18:26:01] what you are proposing is a protocol standardization issue. As a result it is supposed to be discussed on afs3-stds first. Then once consensus is acheived and the protocol change documented, the registrars are to issue the necessary values [18:27:15] --- edgester has left [18:28:08] last Summer there was a heated debate where some members of the developer community objected to the OpenAFS gatekeepers being able to make defacto protocol changes by implementing code in OpenAFS being that OpenAFS is the most widely used implementation. [18:28:32] As a result the standardization process was agreed upon. [18:31:47] the standardization process permits the allocation of implementation specific RPCs. However, even for those RPCs the assignments must come from the registrar. [18:32:02] my understanding was that rx osd, since it has been out and available, pre-dates that process and would be handled via registrar + gatekeepers and only go through that process where specifically needed (the term I heard used was 'grandfathered') [18:32:30] that was Derrick's statement [18:33:33] my statement was that where there are protocol conflicts there is a standards issue that must be resolved [18:33:54] so, is rx osd grandfathered or not? [18:34:16] I'm inferring you are saying 'not', but I want to make sure I'm not making an incorrect assumption. [18:34:55] Jumping in here ... [18:34:55] What Derrick also said was that for the parts of rx osd which can be folded in without conflict we would do so. [18:35:28] My view was that rxosd is grandfathered, in that we don't expect full protocol specifications, discussion, or protocol changes based on that discussion. [18:35:37] the problem is that Derrick made the "grandfathered" statement before we discovered the protocol conflicts [18:35:56] But not in that it can use pioctls which have been assigned to others. [18:36:09] or protocol fields [18:36:13] And then, there's the whole issue of all of the other things it 'acquires' [18:36:16] exactly. [18:36:22] what is 'acquires'? [18:36:47] It uses some relatively scarce protocol fields for its own ends. [18:36:54] ah, ok. right. [18:36:58] there are flags that rx osd allocates for existing protocol messages that are already in use and previously unused fields that are also in use [18:37:06] > but Git isn't as good about pullups [18:37:18] dude, what? the pullup script for grand is totally an ugly ugly script. [18:37:24] i fail to see how anything could be worse [18:37:24] --- abo has left [18:37:51] --- abo has become available [18:38:03] so...back to rx osd... [18:38:22] > Well, the Mozilla review process isn't always as formal as it seems. [18:38:26] My hope would be that as rxosd is there, working, and people want to use it, unreasonable barriers won't appear to it using those fields (and, I suspect that it may have an easier ride than a 'new' extension that's trying to use them). [18:38:44] mozilla lost as a model in my mind when i didn't get addressbook support in thunderbird for like 4 years. [18:38:46] This is where Derrick brings up the Mac OS X address book. [18:38:51] when the code existed for all 4 of those years [18:38:59] bingo. Do I get my money now? [18:39:22] --- mcohan has left [18:39:39] I don't know how we can ship rx osd as it is deployed by hartmut. the fields he is using are already in use. [18:39:51] agreed. [18:40:06] > Er, sorry. Our current web-centric implementation. [18:40:17] vitroth has modules that fix that. we never took them. [18:40:19] --- mcohan has become available [18:40:20] what I've been trying to do is pull out the non-core 'goodies', but those rely on pioctl renaming/new ones, new rpcs, etc. [18:40:24] > There is no non-web interface for doing anything else. [18:40:26] lies. [18:41:09] so do I need to go through afs3-stds process for each of those separately? for them as a group? something else? [18:41:53] Well, I'd love someone to go through the afs3-stds process. But as we still haven't finished that, perhaps not yet ... [18:42:16] I also think part of the 'grandfathering' was an expectation that rxosd wouldn't be expected to go through that process. [18:42:24] even if it isn't formally used, it is the process we have to discuss protocol implications [18:42:49] > First, pioctls should not be renamed after assignment. [18:42:50] Yes. But I'd hope that those bits of rxosd which _don't_ have implications can bypass some of the formalities. [18:42:50] and as a result I believe that protocol implications should be forwarded there for review [18:43:05] someone probably addressed this in the messages i am still reading, but istr these were never assigned [18:43:42] if it involves a pioctl value or a field or flag bit in an existing message, it has protocol implications that should have a light shown on it [18:44:14] Yes - reusing existing things, or extending existing structures should definitely be discussed widely. [18:44:19] > I don't want subtle changes like this to slip through without the necessary review [18:44:35] But, we don't really need a protocol spec for every new rxosd RPC, do we? [18:44:37] there was no slip about the change. it was a deliberate choice. [18:45:38] > my statement was that where there are protocol conflicts there is a standards issue that must be resolved [18:45:48] i agree; the grandfathering doesn't override that [18:46:18] I'm not suggesting a protocol spec. I am suggesting that as steven is reviewing this code that an e-mail be sent to afs-stds indicating that patch blah blah blah has been submitted to openafs RT. The rx osd code uses these pioctl values, these message fields, and/or these flag bits [18:47:39] caught up. sorry. simon, yes, you can collect a pint next time you see me [18:48:01] and then someone needs to go and look to see if anything is using those piocols, message fields, or flag bits. If so, they need to be allocated other values. and in any case, be registered [18:48:01] and yes, simply registering would meet my concerns also [18:48:56] secureendpoints - that process seems reasonable to me. and it addresses my concern about keeping communication between gatekeepers, registrars, and developers in sync. [18:50:33] now, all that said, i think the registrar's published documents are out of date. regardless, no mention of the mr-afs pioctls appears there, and on the basis of it was not a rename of a registered url, and the wire protocol was the same, i opted for "don't care". i still think that's a prudent option, and if there's a library issue, export the old function names, too [18:50:42] a question here: how much pondering on my own should I do wrt some of the changes? e.g., if a patch uses a bit field in a way that I think is risky, should I try to come up with a better idea, or is it ok to just post to the list as-is and ask for better suggestions? [18:51:19] we should probably discuss. [18:51:34] er, a registered "pioctl" [18:52:17] basically if there's something risky we should at least try to accomodate backwards compat with hartmut. in some cases it will just be "nope, sorry". [18:54:13] since most of us have not reviewed the code at all, document what is there and let the rest of us know. [18:54:16] I'm pretty sure some of the stuff is going to be 'nope, sorry'; my main question at this point is 'should I try to come up with something better, or simply post to the list and see if other ideas exist'. Clearly for some stuff, a better way is relatively obvious (cf my recent post about rxgen extensions), but for others, I may not see a better way off-hand. [18:54:41] might as well post first [18:54:46] will do, tx. [18:54:57] if something seems risky to you it probaby is. if you are unaware if it is risky, someone else might know. [18:55:34] jhutz, in particular, has some interesting ideas in that regard. [18:57:28] --- sxw has left [18:59:30] are you referring to his email response or something else? [19:00:18] no. i meant, if you share things you haven't found a problem in, he's someone likely to find one you haven't thought of [19:01:24] got it, tx. [19:36:21] oh, the joys. have the first part of rpc name<->opcode mappings working. [20:12:25] --- dev-zero@jabber.org has become available [20:38:11] --- SecureEndpoints has left [20:50:22] --- Russ has left: Disconnected [20:52:13] --- SecureEndpoints has become available [21:30:34] --- dev-zero@jabber.org has left [22:11:49] --- dev-zero@jabber.org has become available [22:38:19] --- manfred has become available [22:40:13] --- manfred has left [23:03:17] --- reuteras has become available [23:56:47] --- stevenjenkins has left [23:57:16] --- stevenjenkins has become available