CDWG Minutes 2014-07-30
Agenda
- Lustre 2.6.0 status
- Shifting OpenSFS's Lustre focus from adding new features to making Lustre maintable
- One Lustre Working Group To Rule Them All
Attendance
- James Simmons (ORNL)
- Sebastien Buisson (Bull)
- Chris Morrone (LLNL)
- Cory Spitz (Cray)
- Peter Jones (Intel)
Minutes
Lustre 2.6.0 Status
RC2 testing is complete. Just a couple of issues that we are considering whether they should be blockers, and require an RC3.
LU-5420 is one, regression introduced by another recent patch. It broke some DNE configurations (multiple MDTs on one node).
When stress testing LFSCK, problem when extreme numbers of creates during extreme numbers of deletes.
Cray continuing to test 2.6, but testing slow due to fighting other fires. Striped directory testing did not go well. Peter agreed, and said we'll call striped directories in 2.6 a technology preview rather than a supported feature.
Shifting OpenSFS's Lustre focus from adding new features to making Lustre maintable
Document RPCs, state machines All-text documentation in tree.
Cory, rpc state machine so complicated that recent fixed caused two more bugs.
James - locking machine, very fragile. Cory - Cray landed fix there and again caused two other bugs.
James is for protocol documentation and code refactoring.
Kind of like the kernel janitor project - funding by Linux Foundation
One Lustre Working Group To Rule Them All
Peter - with small community, don't really see the point of segragating the development into two groups
Number of folks that join the calls is not too large, and the most active folks tend to be on both calls anyway.
Release Cadence
Good to contemplate. Are we meeting the needs of users and vendors with current cadence? Currently, we shouldn't have feature releases without features. Some vendors expressed concerned that too frequently for them to fully test.
Chris - Perhaps change the release names to change focus: Feature releases become "Development Releases", maintenance releaes become "Stable Releases". That reduces or eliminates the need to delay development releases when features are not ready. A development release can just contain all of the smaller non-feature work and follow the planned release date. The features can slip to a later development release when they are ready.