Skip to content

Meeting 2019 05 31

Jump to bottom
Josh Hursey edited this page May 31, 2019 · 2 revisions

Agenda

Notes

        Joshua Hursey (IBM)
	Geoffroy Vallee (Sylabs, Inc.)
	Stephen Herbein (LLNL)
	Swaroop Pophale (ORNL)
	David Solt (IBM)
  • Reading: https://github.com/pmix/pmix-standard/pull/183
  • Discussion: https://github.com/pmix/pmix-standard/issues/179 (stability classes)
    • Suggestion to add more time to move an interface to last level (maybe a quarter)
    • Do we need more balance between acceptance and depreciation?
      • Should depreciation be faster for lower stability levels?
      • If the depreciation time is too long then the bar becomes higher to bring things in even at lower stability levels.
      • Add to this discussion a definition of the depreciation time per level
    • Circling around a question of “what is the bar for being part of the standard?”
      • Addressing this question might help us resolve the stability classes discussion.
      • Should we have 1 big standard with lots of interfaces, or many smaller standards for each subset of interfaces.
        • Concern is that if it is too small then it becomes inconsequential and excludes participation because of narrow scope. If it becomes too big then it frustrates implementations, and becomes less well defined in purpose.
      • Can we agree on the core list (must have) vs additional list (good to have)?
        • Where we draw the line becomes an issue since it may be determined differently for different users.
        • From a user perspective (client or RM) then it would be nice to isolate functionality classes.
      • Related to https://github.com/pmix/pmix-standard/issues/182 (functionality classes) discussion
      • Do we need a mission statement (or guideline) to judge proposals against to determine if the use case/proposal should be part of the standard?
        • Don’t we have this in the standard now? Maybe it just needs to be clearer.
      • It be useful to enumerate the use cases and how they intersect. This can help define both the ‘core’ and the ‘mission’.
        • Mission may grow based on new use cases put forward to the community.
      • We should create a broader issue about ‘core’ PMIx to capture notes from above.
        • It is related to #182, but is also cross cutting.
  • Discussion: https://github.com/pmix/pmix-standard/issues/175 (implementation agnostic document)
    • Working through the first chapter.
  • Chicken and egg issue in answering ‘what is the core of PMIx and mission’:
    • Need to facilitate better understanding of the PMIx interface and background to know what it can do today and the communities that it is serving.
      • Working groups can serve this purpose by defining functionality classes, defining use cases, and separating the implementation from the specification. These activities all require digging deep into PMIx.
    • Working groups would find it helpful to have broad ‘core’ and ‘mission’ guidelines to structure their investigation
      • Guidelines are difficult to define in general terms that are not overly restrictive to new use cases (or existing use cases seen as isolated subsets) that should be part of PMix.
  • Naming discussion (June 14):
    • Discussion on this topic on the mailing list has stopped. Concern is that since discussion is no longer active on the mailing list then the June meeting may not reach a resolution.
      • We will keep the meeting and hope for a resolution on naming, but realize that more discussion may be needed depending on what folks are thinking.
      • Discussion is both related to the ‘core’ and ‘mission’ discussion, and can be seen as orthogonal to it. This may complicate the discussion.
  • PR templates merged:

Action Items

  • (Geoffroy) Create issue regarding defining ‘core’ PMIx
  • (Josh) Create a generic ‘Wireup’ use case

Home

Working Groups

Events

Helpful How To...

ASC Quarterly Meetings

ASC Monthly Meetings

Clone this wiki locally