LWG Minutes 2019-08-08

Attendance

Cray: Cory Spitz, Ben Evans
HPE: Olaf Weber, Christopher Voltz, Jeff Garlough
SuperMicro: Abe Asraoui
IU: Ken Rawlings
CEA: Jacques-Charles Lafoucriere
Whamcloud: Joe Gmitter, Peter Jones, James Nunez, Andreas Dilger

Actions

New Actions Captured:

• None

Existing Open Actions:

• None

Actions Recently Closed:

• None

Minutes

2.13.0 Release Update
Peter

• Oleg has been doing some more landings. Something is awry in the latest set of patches under consideration that is causing a lot of crashes. We are trying to isolate which patch(es) could be causing the problem.
• RedHat 7.7 has come out, will be rolled into 2.13. We will need to wait for the CentOS version for patched server support.
• Which SLES version should we have client support for in 2.13, should we be moving to SLES15?
  • Cory: SLES should be moved up for 2.13. as it is not an LTS and can be more forward looking.
• Peter: Everyone should review 2.13 tickets. This is a good filter to use: https://jira.whamcloud.com/issues/?filter=15526
  • We have had a lot of issues added to 2.13 list from Alibaba Cloud.
  • (Conducted a ticket review for a few selected tickets).

Upstream Lustre Client
Peter (James not present)

• James is working with Neil to bring client up to 2.11 level. He is about half way through reviews on all the ports.

lustre.org
Ken

• We have continued to work on the upgrades to infrastructure pieces and are now fully up to date.
• Turning our focus to wiki.lustre.org next.

Other Business

• Peter: We have our core RedHat server support and we focus our testing on that for releases. We also have some groups that are interested in SLES or Ubuntu, as well as some that are very interested in patchless server support. One thing that has come up a few times now is that someone pushes a fix for something and just includes fixing for RedHat. James immediately usually gives it a -1 and says the fix is needed across the board for all distros. What is the expectation there? Developers often don’t have access to other distros to test blind changes. Are we trying to support all of them for every bug fix in an effort to keep them working even if we can’t test them to the same degree for verification? Any feedback?
  • Cory: What feedback did Oleg have on it?
  • Peter: His feedback had no particular strategy for dealing with it. Oleg gets a fix that he agrees works and should land but then it gets a -1 due to not having the fix against other distros that other interest groups find useful. Where does the responsibility reside? Do we require developers to submit fixes for every distro? This could delay getting useful fixes. Alternatively, do we land stuff first for primary kernel versions we support and those that have an interest in Ubuntu , servers, for example, need to watch for landings that would be needed to be fixed there too and submit those patches?
  • Cory: A policy could be created to say that if someone contributes a patch for one kernel, then we immediately create a new ticket that will note and track that the other distros also need to address this change.
  • Peter: This is a good idea and it will have a record and be tracked for those that want to pick up that work while the primary patch lands.
  • Peter: Let's table the discussion there and wait for James’ input on the next call.

Next meeting will be on 2019-08-22 at 11:00am Pacific