LWG Minutes 2017-05-04

Attendance

Cray: Cory Spitz, Ben Evans, Justin Miller
ORNL: James Simmons
Sandia: Ruth Klundt
IU: Ken Rawlings
SuperMicro: Abe Asraoui
Intel: Andreas Dilger, Joe Gmitter, Peter Jones

Actions

New Actions Captured:

• None

Existing Open Actions:

• None

Actions Recently Closed:

• None

Minutes

2.10 Release Update
Peter

• Things are progressing fairly well. We have seen some crashes in our testing and are working on landing those patches. Oleg plans to land a batch today and these fixes will hopefully be in the next batch early next week.
• Does anyone else have any input regarding 2.10 testing?
  • James: Tuesday we have a second test shot for PFL. We have been doing small scale testing and now moving up to medium scale (500 clients, 56 OST)
• Ben, regarding LU-9221, how are things progressing with this work?
  • Ben: I have been working on HSM patches, will be getting back to this very soon.
• James: sysfs work turning out to be an ugly mess. There have been quite a few issues with it.

Lustre Roadmap
Peter

• The proposed updated roadmap has been circulated. Did anyone have a chance to look at it it? Any feedback or is it good to go?
  • Cory: People are going to zero in on the asterisk and see if they can figure out what it means. Can we explain it better?
    • Peter: Yes, we can probably do something there. I hope to refresh it after 2.10.
• Cory: Should we make the LTS branch something that is always releasable if we always have the right amount of testing before the gatekeeper puts a fix on there?
  • Andreas: That is what we have done with the EE branches in the past. Everything going in there is already landed to master and vetted through multiple levels of testing.
• Cory: What if each patch landing generates a new release?
  • Peter: It really depends on what type of validation you want on each release. If you are looking for only basic functional regression this would be practical if that is all that is required. However, scale testing, performance, upgrade/downgrade testing are currently done on releases now and that would not be practical to do for each individual patch.
• Cory - What is the community philosophy going to be for the gatekeeper approach?
  • Peter: i don’t see an advantage of every bug fix going onto LTS branch. It would be great if the developer would say that this bug also affects the LTS branch and pushed a patch there as well. Otherwise, we will have to use our Jira FixVersion planning to get attention for a given release.
  • Andreas: As long as we do a good job with keeping the ordering of patches and such relatively sane, we should be able to cherry pick easily within gerrit.
• Peter: The other big question will be how often do we plan to change LTS release. Working on a good answer before LUG. Any opinions? 18 months? 24 months?
  • Andreas: Probably 18 months would be the shortest that we would want to go.
  • Peter: This is somewhat similar to Ubuntu, where they have interim cutting edge release in between LTS releases and may have an LTS bug fix release until the next major release comes out.
  • Cory: I would be good with the 18 month window.
• Peter: Is it agreed to upload the draft now and then revise it later with further details when we have release strategy mapped out?
  • All in agreement.

Upstream Lustre Client
James

• No significant news this week.

lustre.org
Ken

• We are formalizing webmaster procedures and keeping up momentum on the internal project.
  • Andreas: I poked my head into google doc for LU internals. I won’t be able to spend too much time on it, but I am going through it in a few paces and reading/editing a few things.
    • Ken: That reminds me, edits are showing up as anonymous. We are figuring out best approach as to how to track changes. Would logging in be a road block for people?
    • Andreas: I don't think it is a roadblock. I just wasn't signed into google at the time.

Other Business

• Peter: Developer day is looking good and shaping up. We now have a draft agenda for it.
  • James: Do people want to hear an upstream client talk or two tracepoint talks?
    • Peter: We can bump the upstream client and just do one on tracepoint. It could be a good idea to give a really high level of progress on the upstream client and identify what is left to get engagement and get people involved.
• Peter: As for the hackathon, Ken has has volunteered to help out. This would be great, especially since he is local.
  • Andreas: What should we do during this time slot? We should give advance notice on what could be available to work on.
  • Peter: We will have a list ahead of time. I was thinking upstream client, items with the easy tag in Jira, list of tests marked as always accept (look at what to fix, if it is still valid, etc…). Any other ideas?
    • James: A perf session with how to debug with it and such would be useful.
    • Joe: I could put together a list of easy items to update in the Lustre manual and the getting started instructions to go along with it.
    • Ken: The list of items of the LU internals project.
    • Justin: I have some ideas for anyone really new to go through test suite for bash mistakes, not checking for return codes, running test suite, etc...

Next meeting will be on 2017-05-18 at 11:00am Pacific