CDWG Minutes 2014-07-30

From OpenSFS Wiki
Jump to navigation Jump to search


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.