Meeting 2019 03 22

        Josh Hursey (IBM)
	Kathryn Mohror (LLNL)
	Stephen Herbein (LLNL)
	Aurelien Bouteiller (UTK)
	Jim Garlick (LLNL)
	Ken Raffenetti (ANL)
	Barry Rountree (LLNL)
	Swaroop Pophale (ORNL)
	Thomas Naughton (ORNL)
	Andrew Younge (SNL)
	George Bosilca (UTK)
	David Bernholdt (ORNL)
	David Solt (IBM)
	Tom Scogland (LLNL)
	Gregory Kutzer (Sylabs)
	Nick Radcliffe (Cray)
	Pat McCarthy (Cray)
	Geoffroy Vallee (Sylabs)
	Andrew Younge (SNL)
	Andrew Gontarek (Cray)
	Shinji Sumimoto (Fujitsu)
	Quincey Koziol (LBL)

Agenda:

• Outline the specific goals of these meetings:
  • Refine the PMIx standardization process
  • Create a PMIx standard document that is implementation agnostic
  • Create a wire protocol description
  • Create 'slices'/'levels' in the PMIx standard document for implementation/RFP focus
  • Identify sections of the PMIx interface for further discussion/investigation
  • Others?
• Open discussion of how best to make forward progress on these goals
  • Discussion medium: PMIx Slack, Mailing list, PMIx Standard GitHub Issues, …
  • Break into some working groups?
  • Prefer something that can be archived and referenced (instead of Slack)
  • Break up the effort into ‘chapters’ to focus attention
    • For example, working groups around topics such a wire protocol
    • How to structure the document so we can all make progress on
    • Suggested areas
      • Startup
      • Resource management interface (adding/removing resources)
      • Wire protocol
        • How the client interacts with the server
    • Client side interface
      • Can we think of the client and server as a service?
    • Server side interface
      • Distinguish between additional functionality vs implementation details.
      • Maybe establish this as an additional document or clearly distinguish between client and server
      • Alternatively define the wire protocol to the server instead of an API (or in addition to)
    • Implementation agnostic document working group
    • Slices/Groupings chapter:
      • Identify (cross-reference) back into the document, or maybe tagging the feature in the document.
      • Avoids replication of information - copy/paste vs back reference
  • Who is the audience for this document - should we group by audience or focus on a specific grouping
    • PMIx library implementor
    • PMIx client user
    • Tools user
  • Red / Yellow / Green light - experimental / deployed / required
    • Some tag or color to identify interfaces that are under discussion or review vs wide deployment/agreement
• Working groups:
  • Implementation agnostic document
    • Use GH Issues and PRs to identify specific changes and sections that need attention
  • Client-side interface
    • Review current interface and identify places where clarification is required
  • Server-side interface + wire protocol
    • Should wire protocol be part of the client or server or alternative to the server?
  • Slices/Groups chapter
    • Suggested document structure (cross-reference vs copy vs ...)
    • Suggested slides/groups:
      • Startup
      • Job resource management (adding/removing resources/nodes)
      • Tool actions
      • Client side interfaces
      • Server side interfaces
      • Tool specific interfaces
• Structure conversation around working groups:
  • Create tickets/issues for specific changes on GH
    • Use Standard document repo https://github.com/pmix/pmix-standard
  • Mailing list for discussion for each working group
    • Start with one mailing list and if volume is a problem then split out
    • PMIx mailing list is the main mailing list for now
    • HPC runtime mailing list - keep it around in case we need it later
• What is the scope of PMIx?
  • Try to prevent scope creep
  • Need to keep this question in mind as we
• IO Middleware
  • Some actions that require compute that does not interfere with the application.
  • For example, segment some cores just for IO activity and communicate between those processes on those cores. Need to do some async transfers but need to stay out of the application’s way.
    • Internal resource manager to coordinate activity of multiple threads within the process.
  • Maybe form a working group to see if the features are available, and if PMIx is the right place for this or if other groups needs to be involved.
  • Swaroop (ORNL) is interested, Quincey will send an email to PMIx mailing list to gather interested folks for investigation

Action items:

• (Josh) Send out working group notes and conversation structure notes to both mailing lists
• (Everyone) Start discussion around specific working groups on the PMIx mailing list
• Topics that slipped to next weeks agenda:
  • Outreach: Who is missing from this meeting that should be involved?
  • Present current PMIx standard process
    • Identify specific procedures in the standardization process that could be improved
• Next Meeting: March 29, 2019