From Diego.Moreno-Lazaro at bull.net Wed Aug 1 14:43:04 2012 From: Diego.Moreno-Lazaro at bull.net (Diego Moreno) Date: Wed, 01 Aug 2012 16:43:04 +0200 Subject: [cdwg] Lustre Maintenance Release Plan In-Reply-To: <50173904.4060801@llnl.gov> References: <5012E5E8.7050400@llnl.gov> <50173904.4060801@llnl.gov> Message-ID: <50194078.1090703@bull.net> Hi CDWG, First of all, thanks for this very interesting point you are dealing with. I think that this release plan really fits in with what Lustre community expects from Lustre and the resources available for testing new releases. But there's still one point which is not totally clear for me: rolling upgrades between releases. I suppose this plan means that a proper transition between maintenance releases is guaranteed but what about feature releases? If I take the example of 1.6, 1.8 and 2.1 I guess it'd be something like: - From 2.1, upgrade to 2.2, 2.3 and 2.4 would be possible. - It wouldn't be possible to upgrade from 2.1 to 2.5, 2.6 or 2.7 without going through the next maintenance release (2.4). So, in consequence, and with regard to maintenance releases: - At the end of life of a maintenance release (for instance, September 2014 for Lustre 2.1), even if a new maintenance release is available (Lustre 2.7) upgrading would not be possible without going though the previous maintenance release (lustre 2.4). What do you think? Diego On 07/31/2012 03:46 AM, Christopher J. Morrone wrote: > Lustre Maintenance Release Plan > ------------------------------- > > Lustre maintenance branches host the releases of lustre that we shall > advertise to the general public as "stable" releases. The goal of a > maintenance branch is to include only bug fixes, to ensure a stable > releases for a significant period of time. > > We currently have a development cadence that puts out a "feature" > release of Lustre every 6 months. This is going reasonably well, and > we plan to continue that process. However, we do not have the > resources to ensure that every six month release is entirely bug-free, > nor do we have the resources to add a new branch every six months that > will receive only bug, and be maintained for years. We are not able > to reasonably support and test that many branches in parallel at our > current level of investment, nor would we wish to, as the testing > requirements rise exponentially as the number of supported branches > increases. > > We have decided that every third feature release, occurring every 18 > months, will also be the beginning of a maintenance branch. Tagged > maintenance releases along the maintenance branch will occur on an > as-needed basis, according to the demands of discovered bugs and their > severity. It is likely that tags will occur more frequently early in > the branch's lifetime, and taper off in the later months and years. > > We plan to make the initially advertised lifetime of a maintenance > branch three years. > > We agreed that Lustre 2.4 will begin the next maintenance branch, which > has a targeted release date of the end of March, 2013. > > None of this precludes ad-hoc maintenance releases on other branches. > For instance, there was discussion in the CDWG that some institutions > plan to run Lustre 2.3, and may need a "mini-maintenance" release to > hold them over until Lustre 2.4. We just note that those > "mini-maintenance" releases will be made as the participants have the > time and desire to work on them, and that they will be made on an > as-needed, and ad-hoc manner. > > We will continue to refine our terminology to help avoid confusion. > > To reiterate, out basic plan of record is: > > - 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 > > Chris > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From adilger at whamcloud.com Thu Aug 2 07:07:06 2012 From: adilger at whamcloud.com (Andreas Dilger) Date: Thu, 2 Aug 2012 00:07:06 -0700 Subject: [cdwg] Lustre Maintenance Release Plan In-Reply-To: <50194078.1090703@bull.net> References: <5012E5E8.7050400@llnl.gov> <50173904.4060801@llnl.gov> <50194078.1090703@bull.net> Message-ID: <636940FA-5C5E-4DCD-9A3D-8569933231D9@whamcloud.com> On 2012-08-01, at 7:43, Diego Moreno wrote: > > First of all, thanks for this very interesting point you are dealing with. I think that this release plan really fits in with what Lustre community expects from Lustre and the resources available for testing new releases. But there's still one point which is not totally clear for me: rolling upgrades between releases. I suppose this plan means that a proper transition between maintenance releases is guaranteed but what about feature releases? If I take the example of 1.6, 1.8 and 2.1 I guess it'd be something like: > > - From 2.1, upgrade to 2.2, 2.3 and 2.4 would be possible. > > - It wouldn't be possible to upgrade from 2.1 to 2.5, 2.6 or 2.7 without going through the next maintenance release (2.4). It isn't yet clear what the policy is for such upgrades. Using 1.6 and 1.8 may be bad examples in this case, because they were in use for such a long time, and were both feature and maintenance releases at the same time. There are two issues here - what versions of Lustre will have interoperable wire protocols, and which betsions will have compatible disk formats? The wire protocol is much more difficult to maintain, because it involves all of the state of the clients and servers, and is visible across all of them. This means that keeping Lustre wire protocol interoperable across many releases would need a huge amount of testing effort, though of course we do our best. With the increasing frequency of major releases, we will likely have to do testing only between the latest feature releases, and maintenance releases, and drop testing with old feature releases older than the most recent maintenance release. On the other hand, the disk format is an internal implementation of the server, and is isolated from other servers and clients. We very rarely change the disk format in an incompatible way going forward. In the past, the main issue has been the config records are not forward compatible. New features like DNE will not create incompatible on disk changes until they are enabled, and we've still worked to allow old 1.8-formatted filesystems to be able to upgrade to DNE. Of course, this effort all has a cost, and that cost can be reduced by limiting the number of different releases we have to support. One of the ways we limit the interoperability testing is to not allow formatting a new filesystem, then running it with an old version of Lustre. This allows enabling new features aitomatically at format time, without worrying about how they can be made to work with older versions of Lustre. So far, I'm not aware of anything that prevents 1.8 from being upgraded to 2.3, but there are definitely features in every release that would prevent new filesystems from being downgraded beyond the version they were formatted on. > So, in consequence, and with regard to maintenance releases: > > - At the end of life of a maintenance release (for instance, September 2014 for Lustre 2.1), even if a new maintenance release is available (Lustre 2.7) upgrading would not be possible without going though the previous maintenance release (lustre 2.4). The Aim question is whether anyone actually does this in practice? If someone has stuck with an old version of Lustre for 3 years, will they want to upgrade immediately to the brand new version, or would they prefer to move to the next maintenance release that has been tested for almost two years? Cheers, Andreas > What do you think? > > Diego > > On 07/31/2012 03:46 AM, Christopher J. Morrone wrote: >> Lustre Maintenance Release Plan >> ------------------------------- >> >> Lustre maintenance branches host the releases of lustre that we shall >> advertise to the general public as "stable" releases. The goal of a >> maintenance branch is to include only bug fixes, to ensure a stable >> releases for a significant period of time. >> >> We currently have a development cadence that puts out a "feature" >> release of Lustre every 6 months. This is going reasonably well, and we plan to continue that process. However, we do not have the resources to ensure that every six month release is entirely bug-free, nor do we have the resources to add a new branch every six months that will receive only bug, and be maintained for years. We are not able to reasonably support and test that many branches in parallel at our current level of investment, nor would we wish to, as the testing requirements rise exponentially as the number of supported branches increases. >> >> We have decided that every third feature release, occurring every 18 >> months, will also be the beginning of a maintenance branch. Tagged >> maintenance releases along the maintenance branch will occur on an >> as-needed basis, according to the demands of discovered bugs and their >> severity. It is likely that tags will occur more frequently early in >> the branch's lifetime, and taper off in the later months and years. >> >> We plan to make the initially advertised lifetime of a maintenance >> branch three years. >> >> We agreed that Lustre 2.4 will begin the next maintenance branch, which >> has a targeted release date of the end of March, 2013. >> >> None of this precludes ad-hoc maintenance releases on other branches. For instance, there was discussion in the CDWG that some institutions plan to run Lustre 2.3, and may need a "mini-maintenance" release to hold them over until Lustre 2.4. We just note that those "mini-maintenance" releases will be made as the participants have the time and desire to work on them, and that they will be made on an as-needed, and ad-hoc manner. >> >> We will continue to refine our terminology to help avoid confusion. >> >> To reiterate, out basic plan of record is: >> >> - 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 >> >> Chris >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From pjones at whamcloud.com Fri Aug 3 18:59:53 2012 From: pjones at whamcloud.com (Peter Jones) Date: Fri, 03 Aug 2012 11:59:53 -0700 Subject: [cdwg] Lustre 2.3 update - August 3rd 2012 Message-ID: <501C1FA9.7040506@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 -support for RHEL 6.3 landed -several patches landed for 3.0 kernel client support; just two patches outstanding http://review.whamcloud.com/#change,1942 and http://review.whamcloud.com/#change,1951 Testing ======= -Testing on the 2.2.92 tag is in progress; testing on the 2.2.91 tag was completed -Now that we are feature frozen for 2.3, each subsequent tag should be converging on release quality. You can assist in the final 2.3 release being higher quality by testing these tags and reporting any issues found in JIRA. 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 Aug 3 20:53:49 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Fri, 3 Aug 2012 13:53:49 -0700 Subject: [cdwg] OpenSFS web site requirements Message-ID: Hi all, OpenSFS is in the process of drafting an RFP for getting the OpenSFS web site revamped. I've been directed by the execs to gather requirements from the CDWG for the web site. There is a draft RFP on the OpenSFS home page which does try to capture some requirements (http://www.opensfs.org/wp-content/uploads/2011/03/opensfs.org-RFP_sss5.pdf). Some information in the RFP is dated since OpenSFS now has a functional wiki at http://www.opensfs.org/foswiki/bin/view/Main/WebHome. I have not had time to add any CDWG content yet but hope to start soon. I recommend checking out the wiki's functionality and sending in any feedback you may have. Here is the start of a list of web site requirements to get us thinking about what we need/want: * When one "googles" Lustre, the OpenSFS web site should be at the top of the list or close to it * Emulate linuxfoundation.org especially with regard to how working groups are handled * Working group pages should be managed by the working group leads and facilitate accessing the OpenSFS wiki Web site requirements will be the topic of our next conference call but please feel free to respond to this email with your ideas. Stay tuned for the announcement of our next conference call. 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 morrone2 at llnl.gov Sat Aug 4 00:37:30 2012 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Fri, 03 Aug 2012 17:37:30 -0700 Subject: [cdwg] OpenSFS web site requirements In-Reply-To: References: Message-ID: <501C6ECA.1040603@llnl.gov> I don't understand this comment: "We have attempted to integrate the wiki http://wiki.lustre.org/index.php/Main_Page into our website. We have not been able to make the wiki work." What exactly did we try? Did Oracle give us the source for that? The top level of that is terribly out of date anyway. But there is content under there that we could likely copy (where legal to do so). But I'd drop that statement altogether. What we tried in the past isn't particularly useful to a web designer. Instead we need to focus on telling the web designer what we want. Here's another thing we should drop: "Wiki – attempted to integrate MediaWiki; it was too cumbersome and difficult to use and explain to our working group leads. We need something with a easy interface like wikipedia" Not sure why they would need to know that. The we can choose any wiki we want and set it up independently of the more static web pages. I think what we want are really two sets of web pages, with somewhat different styles. 1) OpenSFS (opensfs.org, www.opensfs.org) 2) Lustre (lustre.opensfs.org) OpenSFS's pages should be all about the organization, what it does, who its members are, lists of activities, etc. The Lustre pages on the other hand should not have "OpenSFS" branding across the top of the page; they should say "Lustre". The OpenSFS sponsorship should be noted, but more subtly along the bottom. E.G. "brought to you by OpenSFS". The Lustre pages need to focus on Lustre: what it is, how to get it, where to go for help, where to go to get involved in development. This comment looks bad to me too: "Platform/software; currently using Wordpress. We need to be able to edit with WYSIWYG editor." I think that we would either have a CMS, where content can be edited through the web, or use more static pages that are styled through CSS, and you can edit the html page in any text editor. Requiring that the entire page be edited through a WYSIWYG editor probably contrains designers to using proprietary and expensive tools, which will make maintenance more obscure and difficult for those of us involved with changing information on the web pages in the future. I think we probably need to keep our "requirements" more high level like this when we start the contract. It looks like the current pdf takes more of a brain-dump approach to listing every possible thing we'd want to mention in the web pages. I would question whether the entire table labeled "Audience" should appear in the document at all. I imagine that a good web designer will ASK us what the content should be and how it needs to be organized, and we would iterate on the look, content, and organization with the developer many times. For intance, it is to early to call out details like "we need a link to our revision control system" or "we need a link to our issue tracker". That is just content. The things we should probably consider and state are: 1) Do we want a CMS? Or do we just more-or-less static web pages + CSS? 2) Should we state that the pages must be generated by, hosted on, and editable from Open Source tools? 3) Should state that the pages must render reasonably well in a variety of browsers (Firefox, Safari, IE, just as examples), and perhaps make correct rendering in a specific set (including version number) part of the requirement. 4) "Search engine optimization". Should include reasonable meta data and organization so that search engines can properly index the pages. I like the "Structure" section. But I would argue, as I did earlier, that weed need two portals: one for OpenSFS, and one for Lustre. Under "Capability/features", there are some things that I don't understand. Do we really need our own calendaring solution, or do we just need a links to google calendars? If it is just links then it is content, and not a capability/feature. I would say the same for wiki and forum. I don't see a need for complicated functionality here. Solutions already exist that work well, we just need links to them. So then these things are just content, not capability/features. Under "Capbility/features" it says "Scroll bar". What is that??? Commerce: really??? A system for processing money built-in to the site is going to be a great expense for something that we use infrequently (LUG). Can't we handle that through existing services external to the opensfs site? Ah, in the "AVAILABLE TECHNOLOGY RESOURCES/INTEGRATION ISSUES", it gives a clue that WYSIWYG is just being used incorrectly. We don't want WYSIWYG really, just interface that normal folks can use. "Content editing through web pages" (implying a CMS) might be a better phrase. Thats all for now, Chris On 08/03/2012 01:53 PM, Hamilton, Pam wrote: > Hi all, > > OpenSFS is in the process of drafting an RFP for getting the OpenSFS web site revamped. I've been directed by the execs to gather requirements from the CDWG for the web site. There is a draft RFP on the OpenSFS home page which does try to capture some requirements (http://www.opensfs.org/wp-content/uploads/2011/03/opensfs.org-RFP_sss5.pdf). > > Some information in the RFP is dated since OpenSFS now has a functional wiki at http://www.opensfs.org/foswiki/bin/view/Main/WebHome. I have not had time to add any CDWG content yet but hope to start soon. I recommend checking out the wiki's functionality and sending in any feedback you may have. > > Here is the start of a list of web site requirements to get us thinking about what we need/want: > > * When one "googles" Lustre, the OpenSFS web site should be at the top of the list or close to it > * Emulate linuxfoundation.org especially with regard to how working groups are handled > * Working group pages should be managed by the working group leads and facilitate accessing the OpenSFS wiki > > Web site requirements will be the topic of our next conference call but please feel free to respond to this email with your ideas. Stay tuned for the announcement of our next conference call. > > 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 > > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > From hamilton5 at llnl.gov Mon Aug 6 15:59:32 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Mon, 6 Aug 2012 08:59:32 -0700 Subject: [cdwg] OpenSFS web site requirements In-Reply-To: <501C6ECA.1040603@llnl.gov> References: <501C6ECA.1040603@llnl.gov> Message-ID: Thanks for the input, Chris. I agree with you that the web site RFP needs works and your suggestions are good. Norm, is this something Cindy can help us with or should the CDWG take on rewriting a draft RFP? -Pam > -----Original Message----- > From: Christopher J. Morrone [mailto:morrone2 at llnl.gov] > Sent: Friday, August 03, 2012 5:38 PM > To: Hamilton, Pam; 'cdwg at lists.opensfs.org' > Subject: Re: [cdwg] OpenSFS web site requirements > > I don't understand this comment: > > "We have attempted to integrate the wiki > http://wiki.lustre.org/index.php/Main_Page into our website. We have > not > been able to make the wiki work." > > What exactly did we try? Did Oracle give us the source for that? The > top level of that is terribly out of date anyway. But there is content > under there that we could likely copy (where legal to do so). > > But I'd drop that statement altogether. What we tried in the past > isn't > particularly useful to a web designer. Instead we need to focus on > telling the web designer what we want. > > Here's another thing we should drop: > > "Wiki - attempted to integrate MediaWiki; it was too cumbersome and > difficult to use > and explain to our working group leads. We need something with a easy > interface like > wikipedia" > > Not sure why they would need to know that. The we can choose any wiki > we want and set it up independently of the more static web pages. > > I think what we want are really two sets of web pages, with somewhat > different styles. > > 1) OpenSFS (opensfs.org, www.opensfs.org) > 2) Lustre (lustre.opensfs.org) > > OpenSFS's pages should be all about the organization, what it does, who > its members are, lists of activities, etc. > > The Lustre pages on the other hand should not have "OpenSFS" branding > across the top of the page; they should say "Lustre". The OpenSFS > sponsorship should be noted, but more subtly along the bottom. E.G. > "brought to you by OpenSFS". The Lustre pages need to focus on Lustre: > what it is, how to get it, where to go for help, where to go to get > involved in development. > > This comment looks bad to me too: > > "Platform/software; currently using Wordpress. We need to be able to > edit with WYSIWYG editor." > > I think that we would either have a CMS, where content can be edited > through the web, or use more static pages that are styled through CSS, > and you can edit the html page in any text editor. Requiring that the > entire page be edited through a WYSIWYG editor probably contrains > designers to using proprietary and expensive tools, which will make > maintenance more obscure and difficult for those of us involved with > changing information on the web pages in the future. > > I think we probably need to keep our "requirements" more high level > like > this when we start the contract. It looks like the current pdf takes > more of a brain-dump approach to listing every possible thing we'd want > to mention in the web pages. I would question whether the entire table > labeled "Audience" should appear in the document at all. > > I imagine that a good web designer will ASK us what the content should > be and how it needs to be organized, and we would iterate on the look, > content, and organization with the developer many times. For intance, > it is to early to call out details like "we need a link to our revision > control system" or "we need a link to our issue tracker". That is just > content. > > The things we should probably consider and state are: > > 1) Do we want a CMS? Or do we just more-or-less static web pages + > CSS? > 2) Should we state that the pages must be generated by, hosted on, and > editable from Open Source tools? > 3) Should state that the pages must render reasonably well in a variety > of browsers (Firefox, Safari, IE, just as examples), and perhaps make > correct rendering in a specific set (including version number) part of > the requirement. > 4) "Search engine optimization". Should include reasonable meta data > and organization so that search engines can properly index the pages. > > I like the "Structure" section. But I would argue, as I did earlier, > that weed need two portals: one for OpenSFS, and one for Lustre. > > Under "Capability/features", there are some things that I don't > understand. Do we really need our own calendaring solution, or do we > just need a links to google calendars? If it is just links then it is > content, and not a capability/feature. I would say the same for wiki > and forum. I don't see a need for complicated functionality here. > Solutions already exist that work well, we just need links to them. So > then these things are just content, not capability/features. > > Under "Capbility/features" it says "Scroll bar". What is that??? > > Commerce: really??? A system for processing money built-in to the site > is going to be a great expense for something that we use infrequently > (LUG). Can't we handle that through existing services external to the > opensfs site? > > Ah, in the "AVAILABLE TECHNOLOGY RESOURCES/INTEGRATION ISSUES", it > gives > a clue that WYSIWYG is just being used incorrectly. We don't want > WYSIWYG really, just interface that normal folks can use. "Content > editing through web pages" (implying a CMS) might be a better phrase. > > Thats all for now, > > Chris > > On 08/03/2012 01:53 PM, Hamilton, Pam wrote: > > Hi all, > > > > OpenSFS is in the process of drafting an RFP for getting the OpenSFS > web site revamped. I've been directed by the execs to gather > requirements from the CDWG for the web site. There is a draft RFP on > the OpenSFS home page which does try to capture some requirements > (http://www.opensfs.org/wp-content/uploads/2011/03/opensfs.org- > RFP_sss5.pdf). > > > > Some information in the RFP is dated since OpenSFS now has a > functional wiki at > http://www.opensfs.org/foswiki/bin/view/Main/WebHome. I have not had > time to add any CDWG content yet but hope to start soon. I recommend > checking out the wiki's functionality and sending in any feedback you > may have. > > > > Here is the start of a list of web site requirements to get us > thinking about what we need/want: > > > > * When one "googles" Lustre, the OpenSFS web site should be at the > top of the list or close to it > > * Emulate linuxfoundation.org especially with regard to how working > groups are handled > > * Working group pages should be managed by the working group leads > and facilitate accessing the OpenSFS wiki > > > > Web site requirements will be the topic of our next conference call > but please feel free to respond to this email with your ideas. Stay > tuned for the announcement of our next conference call. > > > > 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 > > > > > > _______________________________________________ > > cdwg mailing list > > cdwg at lists.opensfs.org > > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > > From hamilton5 at llnl.gov Fri Aug 10 17:52:26 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Fri, 10 Aug 2012 10:52:26 -0700 Subject: [cdwg] OpenSFS Community Development WG call Message-ID: When: Occurs every 2 weeks on Wednesday effective 8/15/2012 from 9:00 AM to 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 the bi-weekly conference call of the OpenSFS Community Development Working Group. Occurs every 2 weeks on Wednesday effective 8/15/2012 from 9:00 AM to 10:00 AM Pacific. 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: 2177 bytes Desc: not available URL: From hamilton5 at llnl.gov Fri Aug 10 18:02:15 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Fri, 10 Aug 2012 11:02:15 -0700 Subject: [cdwg] Reminder - OpenSFS CDWG bi-weekly calls resuming on 8/15 Message-ID: Hi all, This is a reminder that we will be resuming our bi-weekly CDWG calls, at 9am Pacific beginning on August 15th (Call-in: 866-914-3976 (925-424-8105) Passcode: 534986#). Here is the agenda for the 8/15 call: o Web site requirements 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 Richard.Vanderbilt at netapp.com Tue Aug 14 17:51:56 2012 From: Richard.Vanderbilt at netapp.com (Vanderbilt, Richard) Date: Tue, 14 Aug 2012 17:51:56 +0000 Subject: [cdwg] Benchmarking Work Group under OpenSFS is requesting your participation for our research. In-Reply-To: References: Message-ID: [C:\Users\rvanderb\Downloads\Image_0] August 14, 2012 To the scalable parallel file systems community, The Benchmarking Work Group (BWG) under OpenSFS is seeking volunteers from the scalable parallel file systems community to participate in a survey to assist us with our research to characterize I/O workloads. This research will help us identify performance evaluation and benchmarking tools which you or your storage provider can run on your existing scalable parallel file system or on the next one you are planning to acquire and deploy. The survey is voluntary and, all data returned to the OpenSFS BWG will be anonymized before public release. There are no mandatory fields. The BWG appreciates whatever answers you can give. The data received will only be used to help with our research. To assist with the collection of the data, the BWG has assembled a few useful scripts to run. If you have any questions regarding the survey please feel free to contact us. For your efforts the Benchmarking Work Group will recommend open source I/O benchmarking tools that best match your workloads. If desired, BWG will connect you with other facilities or companies with similar workloads. For participating in our survey please follow the link: http://www.opensfs.org/wp-content/uploads/2012/07/BWGIOworkloadcharacterizationsurvey-v1.0-15.pdf We sincerely appreciate your support! Sarp Oral PhD., Oak Ridge National Laboratory, Co-chair 1(865)574-2173 Richard Vanderbilt, Netapp, Co-chair 1(408)822-6016 bwg-survey-data@opensfs.org www.opensfs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 1.jpg Type: image/jpeg Size: 631 bytes Desc: Picture (Device Independent Bitmap) 1.jpg URL: From pjones at whamcloud.com Fri Aug 17 20:16:36 2012 From: pjones at whamcloud.com (Peter Jones) Date: Fri, 17 Aug 2012 13:16:36 -0700 Subject: [cdwg] Lustre 2.3 update - August 17th 2012 Message-ID: <502EA6A4.5070808@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 -3.0 kernel client support now landed; NFS exports are known not to work at present but this is being tracked under http://review.whamcloud.com/#change,3624 Testing ======= -Testing on the 2.2.93 tag is in progress; testing on the 2.2.92 tag was completed -Now that we are feature frozen for 2.3, each subsequent tag should be converging on release quality. You can assist in the final 2.3 release being higher quality by testing these tags and reporting any issues found in JIRA. 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 -We expect to branch b2_3 in the near future as we enter the code freeze phase of the release cycle and start limiting landings to only blocker bugfixes. If there is any issue you are aware of that is not presently showing as a blocker that you believe warrants being treated as one then please let me know. Thanks Peter -- Peter Jones Whamcloud, Inc. www.whamcloud.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hamilton5 at llnl.gov Fri Aug 17 21:23:56 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Fri, 17 Aug 2012 14:23:56 -0700 Subject: [cdwg] Summary of OpenSFS CDWG telecon on August 15th Message-ID: Hi all, Here is a summary of the telecon on August 15th from my notes: Attendees: Pam Hamilton, Chris Morrone - LLNL Peter Jones - Intel Cory Spitz, John Carrier - Cray James Simmons - ORNL Nic Henke - Xryatex My apologies if I missed anyone. Some of the topics were: * OpenSFS web site revamp - We discussed the ideas which were presented previously by Chris Morrone. We are considering two sets of web pages, with somewhat different styles. 1) OpenSFS (opensfs.org, www.opensfs.org) 2) Lustre (lustre.opensfs.org) OpenSFS's pages should be all about the organization, what it does, who its members are, lists of activities, working group info, etc. The Lustre pages on the other hand should not have "OpenSFS" branding across the top of the page; they should say "Lustre". The OpenSFS sponsorship should be noted, but more subtly along the bottom. E.G. "brought to you by OpenSFS". The Lustre pages need to focus on Lustre: what it is, how to get it, where to go for help, where to go to get involved in development. These would be simpler, mostly static pages with links off to the OpenSFS wiki, etc. General requirements would include: 1) Content editing through web pages 2) Pages must render reasonably well in a variety of browsers (Firefox, Safari, IE, just as examples) 4) "Search engine optimization". Should include reasonable meta data and organization so that search engines can properly index the pages. ACTION: Present our ideas to a company who may be engaged to do the implementation. ACTION: Ask the board for the parameters of what the CDWG can do with regard to this activity without getting permission first. * A question was asked regarding the CDWG maintenance branch recommendations and if there has been any response from the board. To date, there hasn't been any communication from the any of the execs. ACTION: Pam will resend the recommendations to the board and ask for feedback. Silence could be interpreted as acceptance? * There was further discussion about the lack of communication flowing from the board to the working groups. A suggestion was made to follow-up with the community representative on the board, Steve Sims, and ask him to share appropriate board news with the working groups, possibly via a newsletter. ACTION: Pam will follow-up with Steve regarding our communication improvement idea. Next call will be Wednesday, August 29th, at 9am Pacific (Call-in: 866-914-3976 (925-424-8105) Passcode: 534986#) Proposed agenda: * More web site discussion/follow-up * Lustre Roadmap update in preparation of the upcoming LAD meeting - We need to make sure that our roadmap is well communicated to our community and to our board to avoid us advertising conflicting roadmaps. 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 spitzcor at cray.com Thu Aug 23 19:59:26 2012 From: spitzcor at cray.com (Cory Spitz) Date: Thu, 23 Aug 2012 14:59:26 -0500 Subject: [cdwg] Contributor agreement Message-ID: <50368B9E.7090801@cray.com> Hi, http://wiki.whamcloud.com/display/PUB/Lustre+Development states that: > Whamcloud has an open code submission policy that does not require copyright sign-over. Does that mean that there isn't contribution agreement at all any longer? I couldn't find up-to-date info at opensfs.org. Are the CDGW and OpenSFS, WC-Intel, and other organizations in agreement on a contribution policy (or lack thereof)? Thanks, -Cory From peter_bojanic at xyratex.com Thu Aug 23 20:04:53 2012 From: peter_bojanic at xyratex.com (Peter Bojanic) Date: Thu, 23 Aug 2012 16:04:53 -0400 Subject: [cdwg] Contributor agreement In-Reply-To: <50368B9E.7090801@cray.com> References: <50368B9E.7090801@cray.com> Message-ID: <80501C00-C302-4F02-A334-106FC5B67336@xyratex.com> Cory, It was WC's decision, and I'm in agreement, that there be _no_ contributor agreement for the Lustre community tree. The objective here is that no one entity has copyright assignments and the Lustre IP, by design, becomes IP contaminated. This way, no one entity can lay claim to the modern code base -- ever. Cheers, Bojanic On 2012-08-23, at 15:59 , Cory Spitz wrote: > Hi, > > http://wiki.whamcloud.com/display/PUB/Lustre+Development states that: > >> Whamcloud has an open code submission policy that does not require copyright sign-over. > > Does that mean that there isn't contribution agreement at all any longer? > > I couldn't find up-to-date info at opensfs.org. > > Are the CDGW and OpenSFS, WC-Intel, and other organizations in agreement > on a contribution policy (or lack thereof)? > > Thanks, > -Cory > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From pjones at whamcloud.com Thu Aug 23 20:17:57 2012 From: pjones at whamcloud.com (Peter Jones) Date: Thu, 23 Aug 2012 13:17:57 -0700 Subject: [cdwg] [wc-discuss] Re: Contributor agreement In-Reply-To: <80501C00-C302-4F02-A334-106FC5B67336@xyratex.com> References: <50368B9E.7090801@cray.com> <80501C00-C302-4F02-A334-106FC5B67336@xyratex.com> Message-ID: <50368FF5.9010604@whamcloud.com> Absolutely correct. Whamcloud suggested this and gained agreement from OpenSFS, EOFS and (the now defunct) HPCFS before proceeding with the 2.1 release collaboration. On 12-08-23 1:04 PM, Peter Bojanic wrote: > Cory, > > It was WC's decision, and I'm in agreement, that there be _no_ contributor agreement for the Lustre community tree. The objective here is that no one entity has copyright assignments and the Lustre IP, by design, becomes IP contaminated. This way, no one entity can lay claim to the modern code base -- ever. > > Cheers, > Bojanic > > On 2012-08-23, at 15:59 , Cory Spitz wrote: > >> Hi, >> >> http://wiki.whamcloud.com/display/PUB/Lustre+Development states that: >> >>> Whamcloud has an open code submission policy that does not require copyright sign-over. >> Does that mean that there isn't contribution agreement at all any longer? >> >> I couldn't find up-to-date info at opensfs.org. >> >> Are the CDGW and OpenSFS, WC-Intel, and other organizations in agreement >> on a contribution policy (or lack thereof)? >> >> Thanks, >> -Cory >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > -- Peter Jones Whamcloud, Inc. www.whamcloud.com From hamilton5 at llnl.gov Fri Aug 24 17:29:30 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Fri, 24 Aug 2012 10:29:30 -0700 Subject: [cdwg] OpenSFS exec board news Message-ID: Hi Steve, The OpenSFS CDWG has discussed how communication does flow down well from the executive board to the working groups. We had the idea that maybe as the "Community" rep on the board, you would be willing to share appropriate board news with the working groups possibly via a newsletter. What do you think? Cheers! 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 ssimms at iu.edu Fri Aug 24 20:50:12 2012 From: ssimms at iu.edu (ssimms at iu.edu) Date: Fri, 24 Aug 2012 16:50:12 -0400 (EDT) Subject: [cdwg] OpenSFS exec board news In-Reply-To: References: Message-ID: Hi Pam- I think this is a great idea. I remember talking with you when we had the first hands on meeting in Chicago (before we had a community board member). You and your group had done a lot of work and had not received feedback from the board, which I am sure was really frustrating. I would be glad to function as a bridge between the working groups and the board. I'll try to pull relevant information from the bi-weekly Tuesday meetings and push it out in a timely fashion. If you have other thoughts or suggestions, I am open. Thanks for reaching out! Simms On Fri, 24 Aug 2012, Hamilton, Pam wrote: > Hi Steve, > > The OpenSFS CDWG has discussed how communication does flow down well > from the executive board to the working groups. We had the idea that > maybe as the "Community" rep on the board, you would be willing to share > appropriate board news with the working groups possibly via a > newsletter. What do you think? > > Cheers! > 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 Fri Aug 24 21:12:38 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Fri, 24 Aug 2012 14:12:38 -0700 Subject: [cdwg] OpenSFS exec board news In-Reply-To: References: Message-ID: Great, thanks Steve! > -----Original Message----- > From: ssimms at iu.edu [mailto:ssimms at iu.edu] > Sent: Friday, August 24, 2012 1:50 PM > To: Hamilton, Pam > Cc: 'cdwg at lists.opensfs.org'; Quinn, Terri > Subject: Re: OpenSFS exec board news > > > Hi Pam- > > I think this is a great idea. I remember talking with you when we had > the > first hands on meeting in Chicago (before we had a community board > member). You and your group had done a lot of work and had not > received > feedback from the board, which I am sure was really frustrating. I > would > be glad to function as a bridge between the working groups and the > board. > > I'll try to pull relevant information from the bi-weekly Tuesday > meetings > and push it out in a timely fashion. If you have other thoughts or > suggestions, I am open. > > Thanks for reaching out! > Simms > > On Fri, 24 Aug 2012, Hamilton, Pam wrote: > > > Hi Steve, > > > > The OpenSFS CDWG has discussed how communication does flow down well > > from the executive board to the working groups. We had the idea that > > maybe as the "Community" rep on the board, you would be willing to > share > > appropriate board news with the working groups possibly via a > > newsletter. What do you think? > > > > Cheers! > > 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 Mon Aug 27 22:24:50 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Mon, 27 Aug 2012 15:24:50 -0700 Subject: [cdwg] FW: OpenSFS Community Development WG call Message-ID: When: Wednesday, August 29, 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 will have an OpenSFS CDWG call this Wednesday, 8/29, at 9am Pacific. Agenda: * Web site discussion/follow-up * Lustre Roadmap update in preparation of the upcoming LAD meeting - We need to make sure that our roadmap is well communicated to our community and to our board to avoid us advertising conflicting roadmaps. Regards, Pam -----Original Appointment----- From: Hamilton, Pam Sent: Friday, August 10, 2012 10:52 AM To: 'cdwg at lists.opensfs.org' Cc: 'pjones at whamcloud.com'; Leininger, Matthew L.; Reitz, Doug M.; Cory Spitz; Hill, Jason J.; cfaber at gmail.com; Ferber, Dan; Gary, Mark R.; Alexander I Kulyavtsev; Jodi Levi; Felix, Evan J Subject: OpenSFS Community Development WG call When: Wednesday, August 29, 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# Hi all, This is the bi-weekly conference call of the OpenSFS Community Development Working Group. Occurs every 2 weeks on Wednesday effective 8/15/2012 from 9:00 AM to 10:00 AM Pacific. 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: 3169 bytes Desc: not available URL: From hamilton5 at llnl.gov Fri Aug 31 17:03:37 2012 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Fri, 31 Aug 2012 10:03:37 -0700 Subject: [cdwg] Summary of OpenSFS CDWG telecon on August 29th Message-ID: Hi all, Here is a summary of the telecon on August 29th from my notes: Attendees: LLNL - Pam Hamilton, Terri Quinn Intel - Peter Jones, Jodi Levi Cray - Cory Spitz, John Carrier ORNL - James Simmons Xryatex - Nic Henke, Colin Faber My apologies if I missed anyone. Some of the topics were: * Review of Action Items from the last call ACTION: Present our ideas to a company who may be engaged to do the web site revamp. - Our ideas were presented to a company being considered for the contract. They will be working up a quote to give to Norm. Stay tuned. ACTION: Ask the board for the parameters of what the CDWG can do with regard to the web site activity without getting permission first. - Pam passed along the question to Terri Quinn, the LLNL board member. Terri has asked the board for feedback. Stay tuned. ACTION: Pam will resend the CDWG maintenance branch recommendations to the board and ask for feedback. - Pam asked Terri about the best way to get feedback from the board as we haven't gotten any to date and drafting the recommendations was a task given to the CDWG by the board. Terri has resent our recommendations to the board and asked for feedback. Stay tuned. ACTION: Pam will follow-up with the community board rep, Steve Simmons, regarding our communication improvement idea between the board and working groups. - Pam sent Steve the CDWG's request for him to send board news to the working groups. He was agreeable and thought it was a good idea. The board currently is holding bi-weekly conference calls. Other topics discussed: * Lustre Roadmap update in preparation of the upcoming LAD meeting - We need to make sure that our roadmap is well communicated to our community and to our board to avoid us advertising conflicting roadmaps. - Discussion surrounded the proposed updates to the community roadmap (http://wiki.whamcloud.com/display/PUB/Community+Lustre+Roadmap) o 2.1 Maintenance Releases will stop the quarter after 2.4 is released o 2.4 Maintenance Releases will start the quarter after 2.4 is released o The box describing 2.3 content will be updated to reflect reality (ie. what really made it into the final release). o Need to get updates from developers working on 2.4 content o Need to investigate what's being considered for 2.5 content ACTION: Peter Jones will send a draft of the new roadmap to the CDWG mail list. * Peter put forth a proposal to switch from a March/September Feature Release schedule to an April/October schedule. This would move the Feature Freeze date to the end of January rather than the end of December. Having the feature freeze in December has proved problematic due to the holidays and have staff available for code inspections, etc. This proposal is still under consideration since input is required from some key technical people at various sites. * The OS Support Matrix was discussed. Specifically, what will be needed in the 2.4 timeframe. Thoughts for 2.4 were: Server side - RedHat 6 for sure; No RedHat 5 since it was dropped with 2.2; SLES is low priority for Cray at this point. Client side - RedHat 6, SLES 11SP2 for sure; Consider deprecating RedHat 5 and SLES 11SP1. ACTION: Peter will send a proposal to the CDWG mail list. * Lustre version interoperability was discussed. There is a strong case for maintaining 1.8 interoperability with 2.4. Proposal is to drop 1.8 with 2.5. Of course, 2.4 interoperability would be maintained for 2.1 and 2.3. ACTION: Peter will send a proposal to the CDWG mail list. * Redo of the Lustre Development Community Tree Maintenance contract was discussed. The board wants the CDWG to act on this. Pam committed to starting the activity in October. The consensus of the CDWG was that waiting until October is fine. Some preliminary discussions can happen at LAD for those CDWG members attending that meeting. Next call will be Wednesday, October 10th, at 9am Pacific (Call-in: 866-914-3976 (925-424-8105) Passcode: 534986#) Proposed agenda: * Lustre Development Community Tree Maintenance contract 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