From ssimms at iu.edu Wed Sep 5 21:02:03 2012 From: ssimms at iu.edu (ssimms at iu.edu) Date: Wed, 5 Sep 2012 17:02:03 -0400 (EDT) Subject: [Twg] Board Update for 9/4/2012 Message-ID: Hello! I probably know most of you, but for those of you that don't, I'm Stephen Simms and am the community board member for OpenSFS. Pam Hamilton and Terri Quinn made the great suggestion that I function as a liaison between the board and the working groups. Toward that end, I will be sending you periodic updates on what the board is up to and will be available to you if you have questions and/or concerns. Thanks! Stephen Simms ========== Board Meeting for 9/4/2012 OpenSFS Website OpenSFS has approached LoudDog ( http://www.louddog.com/ ), the company responsible for the Whamcloud webpages, to help us retool our web presence. Josh from LoudDog has been talking with Pam Hamilton and Chris Morrone to make sure that the working group requirements are satisfied. Norm has been and will be involved with the CDWG to help define their role in this new web design. LoudDog will also be talking with the board to make sure that the marketing approach has a tone appropriate for our organization. Soon, LoudDog will be sending a proposal to OpenSFS for review which, if reviewed favorably will lead to mock-ups of their proposed design. It is the board's wish to have the new site implemented before SC12. ========== The CDWG was asked by the Board to determine the process for the next official maintenance release for Lustre and a plan for going managing future maintenance releases. At the end of May the CDWG wrote to the board articulating their plan. Chris Morrone's summary of the plan: ·         Next official maintenance branch will be 2.4 (end of March 2013) ·         Official maintenance branches will start every 18 months ·         Official maintenance branches will be supported for 3 years After some discussion about deadlines and schedule slippage, the board came to consensus. The board supports and is aligned with the CDWG's plan moving forward. Thanks to all of you for the time spent working on the plan. ========== The OpenSFS Test Cluster deployed at Indiana University ran its first tests two weeks ago. Chris Gearing and Joshua Kugler of Intel are working with IU Sysadmin, Justin Miller to run Intel's automated Lustre testing framework for the purpose of testing Wang Di's DNE code. From dillowda at ornl.gov Wed Sep 5 21:39:35 2012 From: dillowda at ornl.gov (David Dillow) Date: Wed, 05 Sep 2012 17:39:35 -0400 Subject: [Twg] TWG meeting reminder Message-ID: <1346881175.7689.3.camel@frustration.ornl.gov> Just a reminder that the TWG will be meeting tomorrow, September 6th at 9:30 PT to refresh/reaffirm our prioritized requirements presented to the Board, and to make progress towards issuing RFPs. Meeting details: 715-726-4994 or toll-free 866-304-8294 ID and password: 72090 -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenSFSTWGRequirements2012.pdf Type: application/pdf Size: 251711 bytes Desc: not available URL: From carrier at cray.com Fri Sep 7 17:25:12 2012 From: carrier at cray.com (John Carrier) Date: Fri, 7 Sep 2012 17:25:12 +0000 Subject: [Twg] twg-rfp reflector Message-ID: Just a heads up to those of you who were subscribed to the twg-rfp reflector. In preparation for the next RFP, I have cleared the subscriber list. We will accept new subscription requests to twg-rfp after we complete the draft of the RFP in the upcoming twg meetings. Thanks for your understanding, --jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From carrier at cray.com Wed Sep 12 22:53:19 2012 From: carrier at cray.com (John Carrier) Date: Wed, 12 Sep 2012 22:53:19 +0000 Subject: [Twg] TWG meeting minutes for 2012-09-06 Message-ID: The minutes from our OpenSFS TWG meeting last week are attached. Please send comments and/or corrections to the reflectors. We will continue our discussion of the new development RFP at our next meeting: Thursday, 9/13/2012 @ 9:30a PDT/12:30p EDT Dial-in numbers are 1-715-726-4994 or 1-866-304-8294 Meeting ID and password are 72090 --jc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- OpenSFS Technical Working Group Meeting minutes : 2012-09-06 Concall: start : 9:30a PT Next meeting: Thursday, 09/13/2012 @ 9:30a PDT/12:30p EDT Dial-in numbers are 1-715-726-4994 or 1-866-304-8294 Meeting ID and password are 72090 Attending Name Organization email ----------------- -------------- ---------------------------- Cory Spitz Cray spitzcor at cray.com John Carrier Cray carrier at cray.com Alex Kulyavtsev FNAL aik at fnal.gov Steve Simms IU ssimms at indiana.edu Joshua Walgenbach IU jjw at indiana.edu Dave Dillow ORNL dillowda at ornl.gov Andreas Dilger Intel adilger at whamcloud.com Nic Henke Xyratex nic_henke at xyratex.com Agenda Discuss requirements (http://goo.gl/vYmi1) to be covered in an OpenSFS RFP. Notes [from Dave, edited by John] During the call, we discussed our prioritized categories and attempted to order the requirements within each category. We discussed the importance of pursuing architectural projects that would provide the foundation for future work. In the end, we reduced the list to the following: FS Availability 1. Avoid RPC Timeouts Storage Management 2. HSM and storage management infrastructure 3. OST migration and rebalancing Performance 4. File creation performance 5. Single client I/O performance Lustre Networking 6. Dynamic LNET configuration 7. LNET channel bonding Overall, the final list is a close blending of the priorities of the companies on the board and the community at large. Regarding the projects dropped from consideration: - Scalable fault management was on our original list to the board, but has been dropped for now as we do not want to duplicate on-going R&D efforts. - File creation performance was preferred over single client I/O in recognition of Lustre's primary use case, and both were deemed more important at the present than directory traversal due to recent work in that area. - LNET channel bonding has long been a wishlist item, but we believe that it has a dependency on the configuration mechanisms, so appears lowest on the list of work items. - Improved LNET robustness remains an important topic, but was dropped from this round due to the desire to limit the number of items out for RFP and the belief that some of this work could be addressed as part of the technical debt of the other LNET projects. The ordering of the priorities above should serve as a rough guide as to the importance of each project to OpenSFS, but contracts may be awarded in a different sequence if doing so would allow OpenSFS to achieve a greater impact for the community -- for example if the proposals for avoiding RPC timeouts cost the same as doing all of the other work, it may make more sense to postpone that work item and fund the others. We will discuss the form that the RFP will take at our next meeting. The current thinking is that we will issue one RFP containing each of the above items, but responses will not need to address all areas. Each vendor should be able to respond to each area individually, and may highlight any benefits derived from combining separate requirements under one contract. OpenSFS would expect to evaluate each area as a separate item, and may award contracts to separate vendors. From carrier at cray.com Thu Sep 13 16:41:22 2012 From: carrier at cray.com (John Carrier) Date: Thu, 13 Sep 2012 16:41:22 +0000 Subject: [Twg] FW: RFP Message-ID: For reference, this is the RFP OpenSFS issued last year. Sorry for filling your inboxes, but I wasn't able to get them posted to our wiki in time for today's meeting. --jc -------------- next part -------------- A non-text attachment was scrubbed... Name: opensfs_evaluation_criteria.pdf Type: application/pdf Size: 153451 bytes Desc: opensfs_evaluation_criteria.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: opensfs_metadata_technical_specification.pdf Type: application/pdf Size: 143516 bytes Desc: opensfs_metadata_technical_specification.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: opensfs_proposal_preparation_instructions.pdf Type: application/pdf Size: 175612 bytes Desc: opensfs_proposal_preparation_instructions.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: opensfs_quota_technical_specification.pdf Type: application/pdf Size: 148471 bytes Desc: opensfs_quota_technical_specification.pdf URL: From carrier at cray.com Thu Sep 20 07:25:57 2012 From: carrier at cray.com (John Carrier) Date: Thu, 20 Sep 2012 07:25:57 +0000 Subject: [Twg] TWG meeting minuts for 2012-09-13 Message-ID: The minutes from our OpenSFS TWG meeting last week are attached. Please send comments and/or corrections to the reflectors. We plan to continue discussion of the RFP at our next call Thursday, 9/20/2012 @ 9:30a PDT/12:30p EDT Dial-in numbers are 1-715-726-4994 or 1-866-304-8294 Meeting ID and password are 72090 --jc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- OpenSFS Technical Working Group Meeting minutes : 2012-09-13 Concall: start : 9:30a PT, adjourn : 10:32 PT Next meeting: Thursday, 09/20/2012 @ 9:30a PDT/12:30p EDT Dial-in numbers are 1-715-726-4994 or 1-866-304-8294 Meeting ID and password are 72090 Attending Name Organization email ----------------- -------------- ---------------------------- Cory Spitz Cray spitzcor at cray.com John Carrier Cray carrier at cray.com Alex Kulyavtsev FNAL aik at fnal.gov Steve Simms IU ssimms at indiana.edu Joshua Walgenbach IU jjw at indiana.edu Dave Dillow ORNL dillowda at ornl.gov Andreas Dilger Whamcloud adilger at whamcloud.com Nathan Rutman Xyratex nathan_rutman at xyratex.com Notes John sent the RFP from last year to the TWG reflector (and knows that he needs to put it on the twg wiki along with other docs that appear to have been lost from the opensfs website). DaveD reviewed the notes from last week and the proposed priority order of the requirements: FS Availability 1. Avoid RPC Timeouts Storage Management 2. HSM and storage management infrastructure 3. OST migration and rebalancing Performance 4. File creation performance 5. Single client I/O performance Lustre Networking 6. Dynamic LNET configuration 7. LNET channel bonding There were no objections to this plan. - acceptance criteria We discussed the need for including acceptance criteria in the statement of work resulting from this RFP. If there is no performance improvement, vendors must, at a minimum, show no regression in performance or functionality. These criteria will be negotiated during the SOW. - requirements The RFP needs to be requirements based. The TWG learned the last time that the Board will not accept feature descriptions in the RFP. Instead we must craft the RFP in terms of requirements. The proposals will have to describe how they meet the requirements and what expected gains their solutions will offer. - separating design and implementation Unlike our previous RFP, the requirements cover a broad area and it is not necessarily clear what the correct implementation should be to meet these requirements. We discussed the need to split each RFP into separte investigation and implementation phases. Our current development contracts use the following stages: Scope Statement Solution Architecture High-Level Design Implementation Demonstration Delivery The proposal being discussed would split these into two groups: Investigation Phase Implementation Phase Scope Statement Implementation Solution Architecture Demonstration High-Level Design Delivery Seperating design from implementation will make it easier for vendors to estimate the costs. Estimating the implementation before the design is complete is tricky and prone to errors. For example, Cray structured its HPCS SOW with Sun along these lines (which lead to initial designs for CMD, channel bonding, LFSCK, end-to-end data integrity, etc. follow the link for more info: http://wiki.lustre.org/index.php/Lustre_HPCS_Activities). The last item of Cray's design SOW with Sun was a proposal for the implementation. We could do the same here, or we could issue a separate RFP for the implementation to engage more developers in the program. - proof of concept We discussed the need for considering proof of concept (POC) as a separate stage for new feature development. This should be part of the implementation, but would be used to demonstrate the viability of the proposed design. Successful demonstration of the POC would provide a decision point for continuing development and productiztion of the feature. - number of RFPs We may end up issuing multiple RFPs, but for now, we will create the RFP as a single document with several sub-categories. This will help minimize the admin overhead. In either case, vendors can respond to subsections, not the complete RFP. end 10:32PTq From dillowda at ornl.gov Thu Sep 20 15:17:37 2012 From: dillowda at ornl.gov (David Dillow) Date: Thu, 20 Sep 2012 11:17:37 -0400 Subject: [Twg] TWG meeting minuts for 2012-09-13 In-Reply-To: References: Message-ID: <1348154257.11857.1.camel@lap75545.ornl.gov> On Thu, 2012-09-20 at 03:25 -0400, John Carrier wrote: > We plan to continue discussion of the RFP at our next call > Thursday, 9/20/2012 @ 9:30a PDT/12:30p EDT > Dial-in numbers are 1-715-726-4994 or 1-866-304-8294 > Meeting ID and password are 72090 John and I have both caught conflicts today, so we won't be holding the meeting. Please plan on attending next week. Thank you, and apologies for the late notice. -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office From carrier at cray.com Thu Sep 20 15:22:07 2012 From: carrier at cray.com (John Carrier) Date: Thu, 20 Sep 2012 15:22:07 +0000 Subject: [Twg] no TWG meeting today (9/20/2012) Message-ID: Repeating Dave's previous email to make clear that we have had to cancel today's meeting. --jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From spitzcor at cray.com Thu Sep 20 15:45:42 2012 From: spitzcor at cray.com (Cory Spitz) Date: Thu, 20 Sep 2012 10:45:42 -0500 Subject: [Twg] [Discuss] TWG meeting minuts for 2012-09-13 In-Reply-To: <1348154257.11857.1.camel@lap75545.ornl.gov> References: <1348154257.11857.1.camel@lap75545.ornl.gov> Message-ID: <505B3A26.5030805@cray.com> FYI, attendance may be light next week since folks may be traveling after LAD '12. Thanks, -Cory On 09/20/2012 10:17 AM, David Dillow wrote: > On Thu, 2012-09-20 at 03:25 -0400, John Carrier wrote: >> We plan to continue discussion of the RFP at our next call >> Thursday, 9/20/2012 @ 9:30a PDT/12:30p EDT >> Dial-in numbers are 1-715-726-4994 or 1-866-304-8294 >> Meeting ID and password are 72090 > > John and I have both caught conflicts today, so we won't be holding the > meeting. Please plan on attending next week. > > Thank you, and apologies for the late notice. > From carrier at cray.com Thu Sep 20 20:38:43 2012 From: carrier at cray.com (John Carrier) Date: Thu, 20 Sep 2012 20:38:43 +0000 Subject: [Twg] LNET channel bonding Message-ID: Hi all, Since LNET channel bonding has made it to the TWG's short list of requirements for 2013, I would like to remind the community that Cray already funded the design of such a requirement in 2009. The high level design document is available here: http://wiki.lustre.org/images/e/ee/Channel_Bonding_06_15_09.pdf Is this design still valid? What else would need to be done? If the design still looks good, then I suggest that the RFP for this requirement should move directly to implementation and avoid the cost of another design phase. Please post comments to the reflectors. Thanks, --jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From liang at whamcloud.com Wed Sep 26 07:11:30 2012 From: liang at whamcloud.com (Liang Zhen) Date: Wed, 26 Sep 2012 15:11:30 +0800 Subject: [Twg] LNET channel bonding In-Reply-To: References: Message-ID: <1B92F19B-6B4A-4450-BA2A-C25779228504@whamcloud.com> Hi John, I think most of the design is still valid, but I wouldn't suggest to skip the design phase for a few reasons: - it's a HLD, not a DLD. OpenSFS project process has both HLD and DLD in design phase. - the HLD described this feature as a single project, I'm wondering if it's possible to have multiple phases for it (or sub-projects), which will make it more manageable. - it's worked out three years ago and core LNet has been changed a lot, it could be worth taking time to review it and consider if there's any new complexity or issue based on the latest LNet, i.e: Any potential SMP performance issue if adding this feature. Regards Liang On Sep 21, 2012, at 4:38 AM, John Carrier wrote: > Hi all, > > Since LNET channel bonding has made it to the TWG's short list of requirements for 2013, I would like to remind the community that Cray already funded the design of such a requirement in 2009. The high level design document is available here: > http://wiki.lustre.org/images/e/ee/Channel_Bonding_06_15_09.pdf > > Is this design still valid? What else would need to be done? If the design still looks good, then I suggest that the RFP for this requirement should move directly to implementation and avoid the cost of another design phase. > > Please post comments to the reflectors. > > Thanks, > > --jc > _______________________________________________ > twg mailing list > twg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/twg-opensfs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From carrier at cray.com Wed Sep 26 16:02:20 2012 From: carrier at cray.com (John Carrier) Date: Wed, 26 Sep 2012 16:02:20 +0000 Subject: [Twg] LNET channel bonding In-Reply-To: <1B92F19B-6B4A-4450-BA2A-C25779228504@whamcloud.com> References: <1B92F19B-6B4A-4450-BA2A-C25779228504@whamcloud.com> Message-ID: Liang, Do you think the HLD provides enough guidance that a vendor could respond to an RFP to design _and_ implement the feature? Or do we still need to design and implement separately, as has been proposed at our last meeting? Thanks, --jc From: Liang Zhen [mailto:liang at whamcloud.com] Sent: Wednesday, September 26, 2012 12:12 AM To: John Carrier Cc: twg at lists.opensfs.org; discuss at lists.opensfs.org Subject: Re: [Twg] LNET channel bonding Hi John, I think most of the design is still valid, but I wouldn't suggest to skip the design phase for a few reasons: - it's a HLD, not a DLD. OpenSFS project process has both HLD and DLD in design phase. - the HLD described this feature as a single project, I'm wondering if it's possible to have multiple phases for it (or sub-projects), which will make it more manageable. - it's worked out three years ago and core LNet has been changed a lot, it could be worth taking time to review it and consider if there's any new complexity or issue based on the latest LNet, i.e: Any potential SMP performance issue if adding this feature. Regards Liang On Sep 21, 2012, at 4:38 AM, John Carrier wrote: Hi all, Since LNET channel bonding has made it to the TWG's short list of requirements for 2013, I would like to remind the community that Cray already funded the design of such a requirement in 2009. The high level design document is available here: http://wiki.lustre.org/images/e/ee/Channel_Bonding_06_15_09.pdf Is this design still valid? What else would need to be done? If the design still looks good, then I suggest that the RFP for this requirement should move directly to implementation and avoid the cost of another design phase. Please post comments to the reflectors. Thanks, --jc _______________________________________________ twg mailing list twg at lists.opensfs.org http://lists.opensfs.org/listinfo.cgi/twg-opensfs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at whamcloud.com Wed Sep 26 18:21:25 2012 From: doug at whamcloud.com (Doug Oucharek) Date: Wed, 26 Sep 2012 11:21:25 -0700 Subject: [Twg] LNET channel bonding In-Reply-To: References: <1B92F19B-6B4A-4450-BA2A-C25779228504@whamcloud.com> Message-ID: <5324DA91-AE04-4063-B5FA-BE85B6BEFD3B@whamcloud.com> Hi John, I feel that the HLD does give enough guidance that a vendor should be able to estimate what is required to implement as well as design the feature. However, it would be important to point out Liang's last comment regarding the possible interaction between SMP and Channel Bonding so that can be taken into consideration for the RFP. I also agree with Liang that splitting the project would be helpful in making it more manageable. There seems to be two important parts: 1- Coming up with a way to have a NID refer to a logical grouping of channels. 2- Implementing channel bonding over this logical grouping. Number 1 can be tricky as it is very similar to how the internet had to come up with DNS to logically refer to IP addresses. The proposed design calls for a "bonding server" which, in some ways, is working like a DNS server. That is no small task. Also, if done properly, it has the potential of addressing other LNet issues (i.e. wanting to support DHCP). As such, this is a project unto itself. Doug On 2012-09-26, at 9:02 AM, John Carrier wrote: > Liang, > > Do you think the HLD provides enough guidance that a vendor could respond to an RFP to design _and_ implement the feature? Or do we still need to design and implement separately, as has been proposed at our last meeting? > > Thanks, > > --jc > > From: Liang Zhen [mailto:liang at whamcloud.com] > Sent: Wednesday, September 26, 2012 12:12 AM > To: John Carrier > Cc: twg at lists.opensfs.org; discuss at lists.opensfs.org > Subject: Re: [Twg] LNET channel bonding > > Hi John, > > I think most of the design is still valid, but I wouldn't suggest to skip the design phase for a few reasons: > - it's a HLD, not a DLD. OpenSFS project process has both HLD and DLD in design phase. > - the HLD described this feature as a single project, I'm wondering if it's possible to have multiple phases for it (or sub-projects), which will make it more manageable. > - it's worked out three years ago and core LNet has been changed a lot, it could be worth taking time to review it and consider if there's any new complexity or issue based on the latest LNet, i.e: Any potential SMP performance issue if adding this feature. > > Regards > Liang > > On Sep 21, 2012, at 4:38 AM, John Carrier wrote: > > > Hi all, > > Since LNET channel bonding has made it to the TWG's short list of requirements for 2013, I would like to remind the community that Cray already funded the design of such a requirement in 2009. The high level design document is available here: > http://wiki.lustre.org/images/e/ee/Channel_Bonding_06_15_09.pdf > > Is this design still valid? What else would need to be done? If the design still looks good, then I suggest that the RFP for this requirement should move directly to implementation and avoid the cost of another design phase. > > Please post comments to the reflectors. > > Thanks, > > --jc > _______________________________________________ > twg mailing list > twg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/twg-opensfs.org > > _______________________________________________ > twg mailing list > twg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/twg-opensfs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From carrier at cray.com Wed Sep 26 18:53:39 2012 From: carrier at cray.com (John Carrier) Date: Wed, 26 Sep 2012 18:53:39 +0000 Subject: [Twg] LNET channel bonding In-Reply-To: <5324DA91-AE04-4063-B5FA-BE85B6BEFD3B@whamcloud.com> References: <1B92F19B-6B4A-4450-BA2A-C25779228504@whamcloud.com> <5324DA91-AE04-4063-B5FA-BE85B6BEFD3B@whamcloud.com> Message-ID: Thanks for the feedback, Doug. Given the complexities that you and Liang raise, it sounds like this project might benefit from the separate design phase too. From: Doug Oucharek [mailto:doug at whamcloud.com] Sent: Wednesday, September 26, 2012 11:21 AM To: John Carrier Cc: discuss at lists.opensfs.org; twg at lists.opensfs.org Subject: Re: [Twg] LNET channel bonding Hi John, I feel that the HLD does give enough guidance that a vendor should be able to estimate what is required to implement as well as design the feature. However, it would be important to point out Liang's last comment regarding the possible interaction between SMP and Channel Bonding so that can be taken into consideration for the RFP. I also agree with Liang that splitting the project would be helpful in making it more manageable. There seems to be two important parts: 1- Coming up with a way to have a NID refer to a logical grouping of channels. 2- Implementing channel bonding over this logical grouping. Number 1 can be tricky as it is very similar to how the internet had to come up with DNS to logically refer to IP addresses. The proposed design calls for a "bonding server" which, in some ways, is working like a DNS server. That is no small task. Also, if done properly, it has the potential of addressing other LNet issues (i.e. wanting to support DHCP). As such, this is a project unto itself. Doug On 2012-09-26, at 9:02 AM, John Carrier wrote: Liang, Do you think the HLD provides enough guidance that a vendor could respond to an RFP to design _and_ implement the feature? Or do we still need to design and implement separately, as has been proposed at our last meeting? Thanks, --jc From: Liang Zhen [mailto:liang at whamcloud.com] Sent: Wednesday, September 26, 2012 12:12 AM To: John Carrier Cc: twg at lists.opensfs.org; discuss at lists.opensfs.org Subject: Re: [Twg] LNET channel bonding Hi John, I think most of the design is still valid, but I wouldn't suggest to skip the design phase for a few reasons: - it's a HLD, not a DLD. OpenSFS project process has both HLD and DLD in design phase. - the HLD described this feature as a single project, I'm wondering if it's possible to have multiple phases for it (or sub-projects), which will make it more manageable. - it's worked out three years ago and core LNet has been changed a lot, it could be worth taking time to review it and consider if there's any new complexity or issue based on the latest LNet, i.e: Any potential SMP performance issue if adding this feature. Regards Liang On Sep 21, 2012, at 4:38 AM, John Carrier wrote: Hi all, Since LNET channel bonding has made it to the TWG's short list of requirements for 2013, I would like to remind the community that Cray already funded the design of such a requirement in 2009. The high level design document is available here: http://wiki.lustre.org/images/e/ee/Channel_Bonding_06_15_09.pdf Is this design still valid? What else would need to be done? If the design still looks good, then I suggest that the RFP for this requirement should move directly to implementation and avoid the cost of another design phase. Please post comments to the reflectors. Thanks, --jc _______________________________________________ twg mailing list twg at lists.opensfs.org http://lists.opensfs.org/listinfo.cgi/twg-opensfs.org _______________________________________________ twg mailing list twg at lists.opensfs.org http://lists.opensfs.org/listinfo.cgi/twg-opensfs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From he.huang at intel.com Wed Sep 26 05:16:54 2012 From: he.huang at intel.com (Isaac Huang) Date: Tue, 25 Sep 2012 23:16:54 -0600 Subject: [Twg] LNET channel bonding In-Reply-To: <5324DA91-AE04-4063-B5FA-BE85B6BEFD3B@whamcloud.com> References: <1B92F19B-6B4A-4450-BA2A-C25779228504@whamcloud.com> <5324DA91-AE04-4063-B5FA-BE85B6BEFD3B@whamcloud.com> Message-ID: <20120926051654.GA1070@intel.com> On Wed, Sep 26, 2012 at 11:21:25AM -0700, Doug Oucharek wrote: > ...... > The proposed design calls for a "bonding server" which, in some ways, is working like a DNS server. That is no small task. Also, if done properly, it has the potential of addressing other LNet issues (i.e. wanting to support DHCP). As such, this is a project unto itself. Agree, and without the "bonding server" we can still get most benefits of the Channel Bonding feature. - Isaac From carrier at cray.com Thu Sep 27 16:26:24 2012 From: carrier at cray.com (John Carrier) Date: Thu, 27 Sep 2012 16:26:24 +0000 Subject: [Twg] reminder : no TWG meeting today 9/27/2012 Message-ID: Just a reminder: because many members are at the LAD conference this week, there will be no TWG meeting today. --jc -------------- next part -------------- An HTML attachment was scrubbed... URL: