LWG Minutes 2017-05-18: Difference between revisions

From OpenSFS Wiki
Jump to navigation Jump to search
(Created page with "== Attendance == Cray: Cory Spitz, Justin Miller <br /> ORNL: James Simmons, Dustin Leverman <br /> Sandia: Ruth Klundt <br /> IU: Ken Rawlings <br /> Intel: Andreas Dilg...")
 
mNo edit summary
 
Line 68: Line 68:
<br />
<br />
'''Next meeting will be on 2017-06-15 at 11:00am Pacific'''
'''Next meeting will be on 2017-06-15 at 11:00am Pacific'''
[[Category:LWG]]

Latest revision as of 08:17, 1 February 2018

Attendance

Cray: Cory Spitz, Justin Miller
ORNL: James Simmons, Dustin Leverman
Sandia: Ruth Klundt
IU: Ken Rawlings
Intel: Andreas Dilger, Joe Gmitter, Peter Jones

Actions

New Actions Captured:

  • Cory to speak with Chris regarding the open questions on the NRS delay policy docs (LUDOC-366).
  • Cory to get Ben engaged with Henri for review of LU-9021 patches.

Existing Open Actions:

  • None

Actions Recently Closed:

  • None

Minutes

2.10 Release Update
Peter

  • Our testing has been progressing well. PFL is looking like the long pole at the moment. Large scale PFL testing is likely to be scheduled for early June, however, PFL testing is using the PFL branch due to the Cray client issue.
  • When will Chris be able to get to look at the open questions about the NRS delay policy docs (LUDOC-366)?
    • Cory will speak with Chris to see when this could be pulled in.
  • It appears that Ben has refreshed the LU-9021 work as promised on the last call. Is Ben in contact with Henri for a review? We would want this in the next week or so ignorer to make the cutoff before we are trimmed down to must-fix only.
    • Cory will talk with Ben regarding getting in touch with Henri for review of that work.
  • Peter: The LU-7988 is looking like some of the patches will make it, however, due to the short time frame we are now looking at, it is possible some will not be ready in time.
  • James: Will LU-8703 go into 2.10 or is this slated for 2.10.X/2.11?
    • Peter: This work is not tied to a specific release and patches have been landing as they become ready.
  • James: How are things looking for the LU-8964 patches from Dmitry?
    • Joe: It is looking like we will land two of the three patches, with the framework and write improvements landing. We would like to revise the readahead patch for a 2.10.X release.
  • Cory: Are we expecting LU-20 to be ready in time?
    • Peter: The issue still outstanding here is the dmflaky problem and is being investigated.


Lustre Roadmap
Peter

  • Peter: Did anyone have a chance to look at the roadmap that was circulated?
    • 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 could do something there and we intended to refresh it after the 2.10 release.
  • 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 the branch?
    • Andreas: This is what we have done with EE branches in the past. Everything going in there was already landed to master and vetted through multiple levels of testing. However, that may not translate to the master branch.
  • Cory: What if each patch landing would generate a new release?
    • Peter: It really depends on what type of validation you want on each release. If we are only looking at basic functional regression this would be practical if all that is required. However, scale, performance, and upgrade/downgrade testing is currently done on releases now and that would not be possible with this type of approach.
  • Cory: As a community, what philosophy will we take to the LTS branch? What is the gatekeeper approach going to be?
    • Peter: I don’t see an advantage of every bug fix going onto an LTS branch. It would be great if the developer would say that a bug on master also affects the LTS branch and the developer would push 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 ordering of patches and such relatively sane, we should be able to cherry pick easily within gerrit.
  • Peter: Another big question will be how often we plan to change LTS releases. We are working on a good answer before LUG. Any opinions? 18 months? 24 months?
    • Andreas: 18 months is probably the shortest we would want to go.
      • Cory agrees with the 18 month window.
    • Peter: This is somewhat similar to Ubuntu with interim, cutting-edge release in between LTS releases.


Upstream Lustre Client
James

  • The window looks like it is about to open and James has a bunch a cleanups that will be sent out shortly.


lustre.org
Ken

  • We are getting close to being able to retire the old site.


Other Business

  • Peter: Hackathon looking to be in good shape and the developer day agenda is good and logistics are taken care of. Anything else to discuss around LUG?
  • The next regularly scheduled meeting is cancelled due to LUG.


Next meeting will be on 2017-06-15 at 11:00am Pacific