-
Notifications
You must be signed in to change notification settings - Fork 22
Meeting 2019 06 07
Josh Hursey edited this page Jun 7, 2019
·
2 revisions
- Readings: None
- PMIx standardization process (try to limit to 30 min)
- (Dave) Working group update: Implementation agnostic document
- Meeting Tuesday's at 9 am (Central)
- https://github.com/pmix/pmix-standard/issues/175
- (Stephen) Working group update: Slicing/Grouping of functionality
- Meetings Wednesday's at 11 am (Central)
- https://github.com/pmix/pmix-standard/issues/182
- (Josh) Use Case gathering
- Open GitHub Issues
- Reminder:
- June 14 Meeting: Discussion regarding naming of reference implementation and standard
Joshua Hursey (IBM)
Kathryn Mohror (LLNL)
Geoffroy Vallee (Sylabs, Inc.)
Swaroop Pophale (ORNL)
Thomas Naughton (ORNL)
Artem Polyakov (Mellanox)
David Solt (IBM)
Stephen Herbein (LLNL)
Ken Raffenetti (ANL)
- June 14 Meeting: Discussion regarding naming of reference implementation and standard
- Reaching out to folks:
- Send meeting announcement (send to both pmix-forum and hpc-runtime)
- Reply to original email thread
- Need to enumerate options to discuss (here are some very rough options)
- Rename Standard Interface (e.g., System Runtime Interface instead of PMIx)
- Rename Reference Implementation (e.g., PMIx -> Open PMIx)
- Multiple “mini-standards” (not independent, but governed by the body supporting the use case) per use case grouping
- Starting a blank page
- How do we reach consensus and bring this topic to a close
- Reaching out to folks:
-
https://github.com/pmix/pmix-standard/issues/190
- No clear consensus on ‘core functionality’
- Mission statement (some rough options):
- “Market Driven” approach. Evolve based upon user requests. Stability based on usage/demand. Not unbounded/uncontrolled, but more permissive.
- “Top-to-Bottom” approach. Tighter control over the inclusion based on ‘core’
- “Use case groupings” approach. Define use case groupings that are defined by external groups with support requirements. Organize chapters this way.
- Need for balance in any wording of a mission statement:
- If mission statement is loosely defined then we risk unconstrained growth.
- If mission statement is specifically defined then we risk not being general enough.
- Need to get something in the middle. Hopefully towards the more loosely defined version. Needs to be sufficiently broad.
- Use case groupings / Slices
- Example: MPI Forum could define a PMIx Chapter for their needs and govern what goes into the chapter in collaboration with the PMIx Community. Can have a more strict governance for acceptance than the base PMIx community. This chapter is part of the PMIx Standard document.
- Allows users to easily find the subset of PMIx they want to use.
- Allows RMs/Libraries to easily find subsets of PMIx they want to focus on for their target markets/users.
- We have an obligation to be careful about what we include
- Not a research driven standard - driven by specific use cases…
- Need more documentation around why certain interfaces are present (traceable to the use case) to help folks determine importance to their target users/market
- (Dave) Working group update: Implementation agnostic document
- Working on changes per chapter. See PR below for first effort
- (Stephen) Working group update: Slicing/Grouping of functionality
- Discussing new use case:
- Discussing RFCs to extract use cases
- Starting to form up a way of structuring the use case write ups to add clarity on users and what is required and what is optional (and implications)
- Question about use case descriptions:
- Should it be general concepts or specific users guide for PMIx interface?
- https://github.com/pmix/pmix-standard/issues/191#issuecomment-499519697
- (Josh) Advertise naming meeting to various lists.