[00:47:29] --- dev-zero@jabber.org has become available [02:30:14] --- haba has become available [05:32:39] rxk5 tracking branch. Jeff and I had a discussion which appeared to lead to this. I haven't had a chance to discuss it with Marcus. The problem I see with it is that it appears to be solving no new problem--just keeping rxk5 out of the main line for its own sake. [05:37:06] --- Jeffrey Altman has left: Replaced by new connection [05:37:13] It's a great idea to review the design and the implementation of the code. [05:38:02] Where should review lead? Well, clearly it could lead to requests that various things change. [05:39:44] The protocol design document that jhutz requested earlier this summer will be published in draft in about a week ("by labor day"). [05:44:42] There is, for me personally, another level to this. It's the level at which I track my personal involvement in openafs and the fact that we have had a working implementation of a technology that solves a large and serious transport security problem for openafs--for literally 3 years. And we started -discussion- of initial work to integrate already-extant rxk5 code with Jhutz a full year earlier, in 2005. [05:46:17] That is, yes, four calendar years of developer effort, during which Marcus and I have allocated relatively steady effort keeping the thing alive, improving the code, widening platform support (yes, it supports Windows). [05:54:29] I guess the missing background is that Jeff (Altman) told me that for him, it's just impossible that rxk5 could be in openafs 1.6. [05:59:09] If rxk5 were a new development that everyone interested in the process hadn't had full access to, and known to work, for multiple years (3), I would certainly agree, merging before december would be unconservative. [06:02:35] As it is, I just don't think conservative quite describes how long it's taken us to get this done. [06:05:34] I think code review needs to find issues in the rxk5 implementation, which could lead to it's delivering less security than rxkad. Shipping -that- sort of fault would be terrible. (Though it will be sad if we haven't found such a thing by now.) [06:07:50] I think beyond that, we really shouldn't be focusing on redesigning this version of rxk5, if it means openafs loses an opportunity to really address the encryption problem soon--that seems like a win we should really try for. [06:14:14] If tracking rxk5 on another branch for a little while longer is a help, then sure, but I just think we should be at least -trying- for a merge window in 2009, and I'd like to hear creative ideas about how we could organize our work to potentially achieve that. [06:24:13] --- matt has left [06:24:16] --- matt has become available [06:30:05] --- dev-zero@jabber.org has left [06:38:23] While I'm at it, I'd like to start a discussion about work-in-progress code review. Jeff's idea of a weekly rebased branch, with a gerrit in front, might be a good basis for starting a work-in-process review workflow. [06:59:55] --- matt has left [07:19:00] --- Jeffrey Altman has become available [07:36:29] > rxk5 tracking branch. Jeff and I had a discussion which appeared to > lead to this. actually, this is a good idea. i sort of suspect we will need the same for rxosd "soon" since the code reorg patches we've been pulling in will eventually peter out, and we'll get to things which can't "just ship" without protocol and design review. this is going to be the same. [07:37:51] > It's a great idea to review the design and the implementation of the > code. this isn't a new problem, but it's not like we have a good way to do it now. it's an old problem [07:38:27] > The protocol design document that jhutz requested earlier this summer > will be published in draft in about a week yay! [07:40:31] > I guess the missing background is that Jeff (Altman) told me that for > him, it's just impossible that rxk5 could be in openafs 1.6. as to this, if i could get DAFS proven-stable today, i'd like to push 1.6 pres tomorrow. the existing pace of development doesn't dictate that there couldn't be 1.8 within a half-year. but no, i'm not interested either in pushing out 1.6 longer for "one more major feature" (regardless of which). we can start another feature branch with the goal of it becoming the heir apparent. [07:42:16] > While I'm at it, I'd like to start a discussion about work-in-progress > code review. Jeff's idea of a weekly rebased branch, with a gerrit in > front, might be a good basis for starting a work-in-process review > workflow. the question is whether more than one branch (for each major prong of work) is needed, but i don't think having N instead of 1 of these branches is an issue. once the tools to do it work, run them more than once. it's a good idea on its face, implementation nits aside. [08:40:57] --- matt has become available [08:45:50] What is the current status of DAFS? Are we waiting for more things? Is there specific review and verification to be performed from the openafs side? [08:47:52] I have found review to be incredibly difficult because of the lack of documentation of what it is supposed to be doing. [08:48:39] I don't doubt that. [08:48:43] --- dev-zero@jabber.org has become available [08:48:57] beyond that. we are trying to find sites that would be willing to run it in their test cells but are having a very hard time because last Summer when we made a big push to have people do that it was a waste of their time. [08:50:50] We have DAFS running in single cell environments but it needs to be heavily tested in mixed environments. 1.5 needs to be tested both with and without DAFS in mixed environments [08:51:24] Ok. [08:51:40] At least on MacOS X there are problems with release and rename [08:51:56] When the fileserver is MacOS X? [08:52:01] yes [08:52:11] hm. gerrit unhappy. [08:56:17] i'm still pursuing bugs. i'm running it. it occasionally has displayed issues [08:56:51] it's running on a linux server in the dementia cell (which is certainly mixed) [09:09:44] src/volser/vsprocs.c defines MapHostToNetwork and MapNetworkToHost functions that translate nvldbentry structs. However, it is called with vldbentry structs as well. I propose renaming the functions to hton_nvldbentry() and ntoh_nvldbentry() and add hton_vldbentry() / ntoh_vldbentry() and hton_uvldbentry() / ntoh_uvldbentry() [09:12:33] another alternative is to enforce the use of ubik_VL_GetEntryByIDN() everywhere that MapHostToNetwork or MapNetworkToHost is used. (Although I think those names are horrible) [09:13:41] Pretty long, the latter ones. [09:14:13] its not the length that bothers me. Its the lack of description of what they are converting [09:20:05] nice. someone fixed up the struct in ExamineVolume() (src/volserv/vos.c) to be nvldbentry but continued to call VLDB_GetEntryByID(). Lets blame IBM. [10:42:36] --- dev-zero@jabber.org has left [10:58:04] --- deason has become available [11:31:15] the only instance that appears to be a problem is in src/uss/uss_vol.c http://gerrit.openafs.org/377 should address that. jetty has been kicked. [11:31:16] > However, it is called with vldbentry structs as well. outside of uss? I only see one such call (in uss), but I didn't look very hard [11:31:31] oh, heh [11:35:14] and re: DAFS status, I'm going to send something to edgester soon for the newsletter [11:36:31] basically, right now we're only aware of a couple of issues 'critical' enough to preclude production use, and one has a fix in gerrit (I'd give the number but gerrit is still being weird) [11:36:49] but we haven't been testing OSX [11:36:59] jetty was kicked. try restarting the browser [11:37:48] --- Russ has become available [11:39:10] even a different machine doesn't change it; http://gerrit.openafs.org/gerrit/ appears to be serving fewer files than normal, which is consistent with the usual issue [11:50:51] kicking jetty usually fixes it. it didn't. it will have to wait for someone that has privileges on the machine to take a closer look. [11:55:35] * Russ kicked it some more and gerrit.openafs.org seems to be fine now. [14:20:12] --- dev-zero@jabber.org has become available [14:40:38] --- dev-zero@jabber.org has left [15:06:51] --- haba has left [16:05:50] --- cclausen has become available [16:09:04] --- cclausen has left: Replaced by new connection [17:25:25] --- cclausen has become available [19:27:20] --- cclausen has left: Replaced by new connection [19:46:48] --- RedBear has left [19:47:44] --- RedBear has become available [22:26:46] --- kula has left [23:08:42] --- deason has left