From hamilton5 at llnl.gov Wed Jun 6 01:48:11 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Tue, 5 Jun 2012 18:48:11 -0700 Subject: [cdwg] OpenSFS Community Development WG call Message-ID: When: Wednesday, June 13, 2012 9:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada). Where: Call-in: 866-914-3976 (925-424-8105) Passcode: 534986# Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* Hi all, We are going to hold off closing our survey until after ISC. Are people interested in having a call next Wednesday, 6/13, and continuing our discussion on a long term support strategy for releases? Regards, Pam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2949 bytes Desc: not available URL: From pjones at whamcloud.com Fri Jun 8 16:54:31 2012 From: pjones at whamcloud.com (Peter Jones) Date: Fri, 08 Jun 2012 09:54:31 -0700 Subject: [cdwg] Lustre 2.3 update - June 8th 2012 Message-ID: <4FD22E47.1000604@whamcloud.com> Hi there Here is an update on the Lustre 2.3 release. Landings ======== -A number of landings made - see http://git.whamcloud.com/?p=fs/lustre-release.git;a=shortlog;h=refs/heads/master -Job Stats (LU-694) landed Testing ======= -Testing on the 2.2.54 tag is in progress Blockers ======== -Full list available at http://jira.whamcloud.com/secure/IssueNavigator.jspa?mode=hide&requestId=10205 Other ===== -We will continue to provide periodic updates on our progress on this release. In the meantime, you can always see the landings as they happen at http://git.whamcloud.com/?p=fs/lustre-release.git;a=shortlog;h=refs/heads/master and follow the patch reviews and testing at http://review.whamcloud.com/#q,status:open+project:fs/lustre-release+branch:master,n,z Regards Peter -- Peter Jones Whamcloud, Inc. www.whamcloud.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hamilton5 at llnl.gov Fri Jun 8 21:54:32 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Fri, 8 Jun 2012 14:54:32 -0700 Subject: [cdwg] Agenda items for next OpenSFS CDWG call Message-ID: Hi all, I am planning to hold an OpenSFS Community Development Working Group call next Wednesday, 6/13, at 9am Pacific. Please send me any agenda items you have. Here is what I have so far: * How should branch updates be handled? - submitted by Cory Spitz * Continue discussion about a long term support strategy for releases - Can we decide on a recommendation with regard to what should be the next maintenance release? * TWG requirements - There are two which the TWG think should be owned by us - Improved Lustre Tests - Improved Lustre internals documentation - How to do this? Increase our maintenance contract cost to include these items in scope? Regards, Pam ___________________________________ Pam Hamilton Lawrence Livermore National Lab P.O. Box 808, L-556 Livermore, CA  94551-9900 E-Mail:  pgh at llnl.gov Phone:  925-423-1332          Fax:  925-423-8719 From hamilton5 at llnl.gov Tue Jun 12 15:14:18 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Tue, 12 Jun 2012 08:14:18 -0700 Subject: [cdwg] OpenSFS Community Development WG call Message-ID: When: Wednesday, June 13, 2012 9:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada). Where: Call-in: 866-914-3976 (925-424-8105) Passcode: 534986# Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* Hi all, This is a reminder that we’re having an OpenSFS Community Development WG call tomorrow. Agenda: * How should branch updates be handled? - submitted by Cory Spitz * Continue discussion about a long term support strategy for releases - Can we decide on a recommendation with regard to what should be the next maintenance release? * TWG requirements - There are two which the TWG think should be owned by us: - Improved Lustre Tests - Improved Lustre internals documentation - How to do this? Increase our maintenance contract cost to include these items in scope? Call-in: 866-914-3976 (925-424-8105) Passcode: 534986# Regards, Pam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 3920 bytes Desc: not available URL: From pjones at whamcloud.com Mon Jun 18 13:56:52 2012 From: pjones at whamcloud.com (Peter Jones) Date: Mon, 18 Jun 2012 06:56:52 -0700 Subject: [cdwg] [wc-discuss] Lustre 2.2.0 released In-Reply-To: References: <4F75C3C8.8000207@whamcloud.com> Message-ID: <4FDF33A4.9030204@whamcloud.com> Andrei Lustre 2.1.x is our current maintenance release stream - see http://wiki.whamcloud.com/display/PUB/Lustre+Releases for more details. I do not think that sites who are interested in running Lustre 2.2 should necessarily reconsider their plans in light of this. Yes there are bugs in Lustre 2.2, but there are also bugs on older releases. Not every bug is relevant to every site. Bugs that are reported against Lustre 2.2 are getting fixed and landed for September's upcoming Lustre 2.3 release and so anyone running Lustre 2.2 could apply a patch if necessary. I hope that this helps clarify things. Regards Peter On 12-06-18 1:43 AM, Andrei Maslennikov wrote: > > Hello Peter, > > could you please comment on the fact that now both 2.2 and > 2.1.2 were declared GA. > Should people that moved/were planning to move to 2.2 now > reconsider their plans > and plan to roll back to 2.1.2 instead? > > The 2.2 has in fact some bugs, but it was also put by you in > general availability. > One would naturally expect 2.2.1 to show up, and not 2.1.2... > > Regards - Andrei. > > > On Fri, Mar 30, 2012 at 4:31 PM, Peter Jones > wrote: > > Hi there > > I am pleased to announce that Lustre 2.2.0 has been declared GA > and is available for download at > http://downloads.whamcloud.com/public/lustre/lustre-2.2.0/ > . > > > Release Highlights > > -Asynchronous Glimpse Lock/Statahead (LU925/LU389) Improved > performance accessing object attributes (file sizes/xtime etc) > -Client Parallel Checksums (LU884) Improved support for mmap and > better performance using checksums > -Imperative Recovery (LU580) Faster recovery > -Large Xattrs (LU80) Maximum stripe size raised from 160 to 2000 > -Parallel Directory Operations (LU50) Improved performance when > multiple processes access the same directory in parallel > > Changelog details available at > *http://wiki.whamcloud.com/display/PUB/Changelog+2.2* > > Please log any issues found at http://jira.whamcloud.com > > > Regards > > Peter > > -- > Peter Jones > Whamcloud, Inc. > www.whamcloud.com > > -- Peter Jones Whamcloud, Inc. www.whamcloud.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrei.maslennikov at gmail.com Mon Jun 18 08:43:58 2012 From: andrei.maslennikov at gmail.com (Andrei Maslennikov) Date: Mon, 18 Jun 2012 10:43:58 +0200 Subject: [cdwg] [wc-discuss] Lustre 2.2.0 released In-Reply-To: <4F75C3C8.8000207@whamcloud.com> References: <4F75C3C8.8000207@whamcloud.com> Message-ID: Hello Peter, could you please comment on the fact that now both 2.2 and 2.1.2 were declared GA. Should people that moved/were planning to move to 2.2 now reconsider their plans and plan to roll back to 2.1.2 instead? The 2.2 has in fact some bugs, but it was also put by you in general availability. One would naturally expect 2.2.1 to show up, and not 2.1.2... Regards - Andrei. On Fri, Mar 30, 2012 at 4:31 PM, Peter Jones wrote: > Hi there > > I am pleased to announce that Lustre 2.2.0 has been declared GA and is > available for download at > http://downloads.whamcloud.com/public/lustre/lustre-2.2.0/. > > > Release Highlights > > -Asynchronous Glimpse Lock/Statahead (LU925/LU389) Improved performance > accessing object attributes (file sizes/xtime etc) > -Client Parallel Checksums (LU884) Improved support for mmap and better > performance using checksums > -Imperative Recovery (LU580) Faster recovery > -Large Xattrs (LU80) Maximum stripe size raised from 160 to 2000 > -Parallel Directory Operations (LU50) Improved performance when multiple > processes access the same directory in parallel > > Changelog details available at * > http://wiki.whamcloud.com/display/PUB/Changelog+2.2* > > Please log any issues found at http://jira.whamcloud.com > > Regards > > Peter > > -- > Peter Jones > Whamcloud, Inc.www.whamcloud.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uja at ornl.gov Mon Jun 18 15:26:30 2012 From: uja at ornl.gov (James A Simmons) Date: Mon, 18 Jun 2012 11:26:30 -0400 Subject: [cdwg] [wc-discuss] Lustre 2.2.0 released In-Reply-To: <4FDF33A4.9030204@whamcloud.com> References: <4F75C3C8.8000207@whamcloud.com> <4FDF33A4.9030204@whamcloud.com> Message-ID: <1340033190.19625.127.camel@bohr.ornl.gov> On Mon, 2012-06-18 at 09:56 -0400, Peter Jones wrote: > Andrei > > Lustre 2.1.x is our current maintenance release stream - see > http://wiki.whamcloud.com/display/PUB/Lustre+Releases for more > details. > > I do not think that sites who are interested in running Lustre 2.2 > should necessarily reconsider their plans in light of this. > > Yes there are bugs in Lustre 2.2, but there are also bugs on older > releases. > > Not every bug is relevant to every site. > > Bugs that are reported against Lustre 2.2 are getting fixed and landed > for September's upcoming Lustre 2.3 release and so anyone running > Lustre 2.2 could apply a patch if necessary. > > I hope that this helps clarify things. Hello. Seeing this email and from the working groups phone call shows a lot of confusion over what is supported or maintained. So for the last few days I stepped backed and asked why is everyone confused. What this shows is lack of explaining to the community what a maintenance and a feature release are and how they differ. Also the version scheme is not well defined. First lets define a maintenance branch. The maintenance branch is defines as the branch where no new features are added during its life time. A features branch is one that new improvements are introduced for validation but will not be supported for general production use and bug fixes will not be incorporated. Currently for the 2.X branches we have 2.1.X - maintenance branch 2.2 - feature branch 2.3 - feature branch So here is my proposal to end this confusion. For maintenance branches we start a new number i.e for the next one it would be 3.0.0. At the same time another branch, 3.1 be open for more features. In other words 3.0.0 and 3.1 would be branched off the same root branch but evolve in different ways. Yes for 2.X is a bit different due changes in companies with 2.0 and 2.1. 3.0.0 - maintenance branch 3.0.1 3.0.X 3.1.0 - features branch 3.1.1 3.1.X 3.2.0 - features branch 3.2.1 3.2.X 4.0.0 - maintenance branch I just hope that the 3.0 branch would open up after the 2.3. From morrone2 at llnl.gov Mon Jun 18 16:19:07 2012 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Mon, 18 Jun 2012 09:19:07 -0700 Subject: [cdwg] [wc-discuss] Lustre 2.2.0 released In-Reply-To: <1340033190.19625.127.camel@bohr.ornl.gov> References: <4F75C3C8.8000207@whamcloud.com> <4FDF33A4.9030204@whamcloud.com> <1340033190.19625.127.camel@bohr.ornl.gov> Message-ID: <4FDF54FB.5090801@llnl.gov> On 06/18/2012 08:26 AM, James A Simmons wrote: > Seeing this email and from the working groups phone call shows a lot of > confusion over what is supported or maintained. So for the last few days > I stepped backed and asked why is everyone confused. What this shows is > lack of explaining to the community what a maintenance and a feature > release are and how they differ. Also the version scheme is not well > defined. I agree. I've been advocating for some time that we need to adopt a more Ubuntu-like model. We're already half way there with our every-six-months release. Next I think we need to adopt regular LTS (Long Term Support) releases. Our "maintenance" releases are currently something like an LTS, but they are not well advertised, poorly understood by the community, and currently evolve rather organically. No large site can change major lustre versions every six months. No major vendors will be willing to do that either. I think we all know and agree about that. But if we don't have a clear plan for which releases with be LTS and advertise that AHEAD of time, we'll never sync up on releases, and our limited resources will continue to be divided. Vendors and large sites just can't turn on a dime. We need clear guidance well in advance of a maintenance/LTS release if we are going to plan to move to it in a reasonable time frame. My suggestion: Every 18 months, the release will be designated an LTS release. If we consider 2.1 an LTS release, that would make the release at the end of March 2013 the next LTS release. I don't care too much about the numbering. It could be called 2.4, it could be called 3.0, whatever. What is important is that we plan for it and advertise it well in advance. I think that the March 2013 release will have a combination of many features that people are interested in, including the OSD rework, DNE1, imperative recovery, network request scheduled, just to name a few off the top of my head. I know that LLNL has been testing master for a while now as part of our orion-branch testing, and we will continue to test and hammer it on Sequoia. If we are planning to make that release the next LTS, we will migrate ALL of our testing resources to exercise that work as soon as 2.1 is reasonably stable on our production systems. So my sincere hope is that by the time the March 2013 release happens it will be in much better shape than the 2.1 release was. Chris From adilger at whamcloud.com Mon Jun 18 17:35:39 2012 From: adilger at whamcloud.com (Andreas Dilger) Date: Mon, 18 Jun 2012 11:35:39 -0600 Subject: [cdwg] [wc-discuss] Lustre 2.2.0 released In-Reply-To: <1340033190.19625.127.camel@bohr.ornl.gov> References: <4F75C3C8.8000207@whamcloud.com> <4FDF33A4.9030204@whamcloud.com> <1340033190.19625.127.camel@bohr.ornl.gov> Message-ID: <729CE258-958C-41FB-8BE5-39C0CF0CE71A@whamcloud.com> On 2012-06-18, at 9:26 AM, James A Simmons wrote: > Seeing this email and from the working groups phone call shows a lot of > confusion over what is supported or maintained. So for the last few days > I stepped backed and asked why is everyone confused. What this shows is > lack of explaining to the community what a maintenance and a feature > release are and how they differ. Also the version scheme is not well > defined. Last week we also updated the download site with an explanation of the difference between a feature branch and a maintenance branch, but I agree we could do more to make this distinction more clear. > First lets define a maintenance branch. The maintenance branch is > defines as the branch where no new features are added during its life > time. A features branch is one that new improvements are introduced for > validation but will not be supported for general production use and bug > fixes will not be incorporated. > Currently for the 2.X branches we have > > 2.1.X - maintenance branch > 2.2 - feature branch > 2.3 - feature branch > > So here is my proposal to end this confusion. For maintenance branches > we start a new number i.e for the next one it would be 3.0.0. > At the same time another branch, 3.1 be open for more features. In other > words 3.0.0 and 3.1 would be branched off the same root branch but > evolve in different ways. Yes for 2.X is a bit different due changes in > companies with 2.0 and 2.1. > > 3.0.0 - maintenance branch > 3.0.1 > 3.0.X > 3.1.0 - features branch > 3.1.1 > 3.1.X > 3.2.0 - features branch > 3.2.1 > 3.2.X > 4.0.0 - maintenance branch > > I just hope that the 3.0 branch would open up after the 2.3. I don't think that changing the numbering will make this any more clear. To be honest, I suspect people would think, for example, that the "3.0" release is less stable compared to 3.1. Also, it isn't clear what the distinction in the above numbering is between 3.0.x and 3.1.x? If 3.1.x is considered a maintenance release for the features of 3.1.0, then the distinction between a maintenance branch and a features branch is again meaningless. A better scheme (which matches the above and the current practice) might be that 3-digit release numbers are maintenance releases, and 2-digit release numbers are feature releases. However, what will make the distinction between a maintenance release and a feature release most clear to users is to just state this explicitly in every release announcement, and on the download pages. I agree with Chris that having some advance discussion and agreement from major Lustre sites/users on what should be the next maintenance release is important. While everyone can provide input on this decision, the most important factor is who will be doing the most testing and provide good bug reports. The other issue is that once a branch is chosen for maintenance release, the users need to understand that this will get only bug fixes and updates to track the supported vendor kernels, while new features need to go into the next feature release. Sometimes it may be that users feel they _have_ to use a feature release at some site for some pressing reason (e.g. must-have feature or performance improvement). If it is understood that the path forward for that branch is to move to the next maintenance release when it is available (within 12 months, given that the feature release was made at least 6 months after the previous maintenance release), then that site will still converge on the next maintenance release for long-term support. If they are willing to use a new feature release, they should also be willing to upgrade to the next stable maintenance release as well (possibly after the x.y.1 or x.y.2 bugfix release is made). Cheers, Andreas -- Andreas Dilger Whamcloud, Inc. Principal Lustre Engineer http://www.whamcloud.com/ From adilger at whamcloud.com Mon Jun 18 17:44:02 2012 From: adilger at whamcloud.com (Andreas Dilger) Date: Mon, 18 Jun 2012 11:44:02 -0600 Subject: [cdwg] [wc-discuss] Lustre 2.2.0 released In-Reply-To: <4FDF54FB.5090801@llnl.gov> References: <4F75C3C8.8000207@whamcloud.com> <4FDF33A4.9030204@whamcloud.com> <1340033190.19625.127.camel@bohr.ornl.gov> <4FDF54FB.5090801@llnl.gov> Message-ID: On 2012-06-18, at 10:19 AM, Christopher J. Morrone wrote: > Our "maintenance" releases are currently something like an LTS, but they are not well advertised, poorly understood by the community, and currently evolve rather organically. > > No large site can change major lustre versions every six months. No major vendors will be willing to do that either. I think we all know and agree about that. > > But if we don't have a clear plan for which releases with be LTS and advertise that AHEAD of time, we'll never sync up on releases, and our limited resources will continue to be divided. Vendors and large sites just can't turn on a dime. We need clear guidance well in advance of a maintenance/LTS release if we are going to plan to move to it in a reasonable time frame. I agree, but we can't make that decision in isolation. I agree that advance discussion and notification is important, but there has to be buy-in from the users about this. I'm not totally against someone using e.g. 2.2, since it does provide valuable production feedback for the changes from 2.1 to 2.2, but I think this needs to be done with the understanding that the "maintenance" stream for 2.2 will be 2.3 and then 2.4, and finally 2.4.1, 2.4.2 (assuming that is the next maintenance release). > My suggestion: > > Every 18 months, the release will be designated an LTS release. > > If we consider 2.1 an LTS release, that would make the release at the end of March 2013 the next LTS release. > > I don't care too much about the numbering. It could be called 2.4, it could be called 3.0, whatever. What is important is that we plan for it and advertise it well in advance. > > I think that the March 2013 release will have a combination of many features that people are interested in, including the OSD rework, DNE1, imperative recovery, network request scheduled, just to name a few off the top of my head. I tend to agree. This will be the release that contains a majority of the first round of OpenSFS features (except DNE2 and LFSCK3/4). > I know that LLNL has been testing master for a while now as part of our orion-branch testing, and we will continue to test and hammer it on Sequoia. If we are planning to make that release the next LTS, we will migrate ALL of our testing resources to exercise that work as soon as 2.1 is reasonably stable on our production systems. So my sincere hope is that by the time the March 2013 release happens it will be in much better shape than the 2.1 release was. Cheers, Andreas -- Andreas Dilger Whamcloud, Inc. Principal Lustre Engineer http://www.whamcloud.com/ From morrone2 at llnl.gov Mon Jun 18 20:59:10 2012 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Mon, 18 Jun 2012 13:59:10 -0700 Subject: [cdwg] [wc-discuss] Lustre 2.2.0 released In-Reply-To: References: <4F75C3C8.8000207@whamcloud.com> <4FDF33A4.9030204@whamcloud.com> <1340033190.19625.127.camel@bohr.ornl.gov> <4FDF54FB.5090801@llnl.gov> Message-ID: <4FDF969E.9040905@llnl.gov> On 06/18/2012 10:44 AM, Andreas Dilger wrote: > On 2012-06-18, at 10:19 AM, Christopher J. Morrone wrote: >> But if we don't have a clear plan for which releases with be LTS and advertise that AHEAD of time, we'll never sync up on releases, and our limited resources will continue to be divided. Vendors and large sites just can't turn on a dime. We need clear guidance well in advance of a maintenance/LTS release if we are going to plan to move to it in a reasonable time frame. > > I agree, but we can't make that decision in isolation. I agree that advance discussion and notification is important, but there has to be buy-in from the users about this. Sure, and that is why I've been raising this on OpenSFS calls, at the OpenSFS meeting after LUG, and here on mailing lists. Hopefully we will hear from more members of the community and come to some general agreement. > I'm not totally against someone using e.g. 2.2, since it does provide valuable production feedback for the changes from 2.1 to 2.2, but I think this needs to be done with the understanding that the "maintenance" stream for 2.2 will be 2.3 and then 2.4, and finally 2.4.1, 2.4.2 (assuming that is the next maintenance release). Absolutely. Chris From pjones at whamcloud.com Mon Jun 18 21:53:51 2012 From: pjones at whamcloud.com (Peter Jones) Date: Mon, 18 Jun 2012 14:53:51 -0700 Subject: [cdwg] [wc-discuss] Lustre 2.2.0 released In-Reply-To: References: <4F75C3C8.8000207@whamcloud.com> <4FDF33A4.9030204@whamcloud.com> <1340033190.19625.127.camel@bohr.ornl.gov> <4FDF54FB.5090801@llnl.gov> Message-ID: <4FDFA36F.5080002@whamcloud.com> Just getting back to this now and I think that Andreas has covered most of the points I would have made below. I would like to emphasize though that - contrary to James's definition of a feature release - we _do_ support feature releases for production usage (we have customers running 2.2 in production) and we do land bugfixes throughout the release cycle (Lustre 2.2 contained a superset of the bugfixes in 2.1.1 and more, for example) I can certainly sympathize with Chris's viewpoint that it would be helpful to have a fixed pre-announced cycle for which branches will end up as maintenance release streams. When we announced this scheme over a year ago there were so many variables - the rate of Lustre 2.x adoption, what features would be in which releases, how would Lustre 2.x compare to Lustre 1.8.x in production - that it seemed prudent to make a more informed decision nearer the time. The other aspect not touched upon is that we may not need to stick to this model in the longer-term. We introduced this approach as a way of directing scarce engineering/testing resources where they would have maximum benefit, but as we increase the amount of test automation we have in place, it may become more practical to revisit this decision and provide maintenance releases for a fixed timeline rather than for a targeted release stream. As usual, everything boils down to how much of a priority this is compared to other things we could be spending time on. On 12-06-18 10:44 AM, Andreas Dilger wrote: > On 2012-06-18, at 10:19 AM, Christopher J. Morrone wrote: >> Our "maintenance" releases are currently something like an LTS, but they are not well advertised, poorly understood by the community, and currently evolve rather organically. >> >> No large site can change major lustre versions every six months. No major vendors will be willing to do that either. I think we all know and agree about that. >> >> But if we don't have a clear plan for which releases with be LTS and advertise that AHEAD of time, we'll never sync up on releases, and our limited resources will continue to be divided. Vendors and large sites just can't turn on a dime. We need clear guidance well in advance of a maintenance/LTS release if we are going to plan to move to it in a reasonable time frame. > I agree, but we can't make that decision in isolation. I agree that advance discussion and notification is important, but there has to be buy-in from the users about this. I'm not totally against someone using e.g. 2.2, since it does provide valuable production feedback for the changes from 2.1 to 2.2, but I think this needs to be done with the understanding that the "maintenance" stream for 2.2 will be 2.3 and then 2.4, and finally 2.4.1, 2.4.2 (assuming that is the next maintenance release). > >> My suggestion: >> >> Every 18 months, the release will be designated an LTS release. >> >> If we consider 2.1 an LTS release, that would make the release at the end of March 2013 the next LTS release. >> >> I don't care too much about the numbering. It could be called 2.4, it could be called 3.0, whatever. What is important is that we plan for it and advertise it well in advance. >> >> I think that the March 2013 release will have a combination of many features that people are interested in, including the OSD rework, DNE1, imperative recovery, network request scheduled, just to name a few off the top of my head. > I tend to agree. This will be the release that contains a majority of the first round of OpenSFS features (except DNE2 and LFSCK3/4). > >> I know that LLNL has been testing master for a while now as part of our orion-branch testing, and we will continue to test and hammer it on Sequoia. If we are planning to make that release the next LTS, we will migrate ALL of our testing resources to exercise that work as soon as 2.1 is reasonably stable on our production systems. So my sincere hope is that by the time the March 2013 release happens it will be in much better shape than the 2.1 release was. > > Cheers, Andreas > -- > Andreas Dilger Whamcloud, Inc. > Principal Lustre Engineer http://www.whamcloud.com/ > > > > > > -- Peter Jones Whamcloud, Inc. www.whamcloud.com From hamilton5 at llnl.gov Tue Jun 19 17:33:07 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Tue, 19 Jun 2012 10:33:07 -0700 Subject: [cdwg] Canceled: OpenSFS Community Development WG call Message-ID: When: Wednesday, June 20, 2012 9:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada). Where: Call-in: 866-914-3976 (925-424-8105) Passcode: 534986# Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* Hi all, This week’s call is cancelled. Regards, Pam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2845 bytes Desc: not available URL: From pjones at whamcloud.com Fri Jun 22 14:36:54 2012 From: pjones at whamcloud.com (Peter Jones) Date: Fri, 22 Jun 2012 07:36:54 -0700 Subject: [cdwg] Lustre 2.3 update - June 22nd 2012 Message-ID: <4FE48306.7000909@whamcloud.com> Hi there Here is an update on the Lustre 2.3 release. Landings ======== -A number of landings made - see http://git.whamcloud.com/?p=fs/lustre-release.git;a=shortlog;h=refs/heads/master -2.6.38 client support (LU-506) landed -new IO engine (LU-1030) landed -Note that the feature freeze date (June 30th) is approaching Testing ======= -Testing on the 2.2.57 tag is in progress Blockers ======== -Full list available at http://jira.whamcloud.com/secure/IssueNavigator.jspa?mode=hide&requestId=10205 Other ===== -We will continue to provide periodic updates on our progress on this release. In the meantime, you can always see the landings as they happen at http://git.whamcloud.com/?p=fs/lustre-release.git;a=shortlog;h=refs/heads/master and follow the patch reviews and testing at http://review.whamcloud.com/#q,status:open+project:fs/lustre-release+branch:master,n,z Regards Peter -- Peter Jones Whamcloud, Inc. www.whamcloud.com -------------- next part -------------- An HTML attachment was scrubbed... URL: