Skip to content

Meeting 2022 11 10

Thomas Naughton edited this page Nov 10, 2022 · 4 revisions

Agenda

Attendance

Person Institution
KathrynMohror LLNL
Michael Karo Altair
Aurelien Bouteiller UTK
Thomas Naughton ORNL
David Solt IBM
Ken Raffenetti ANL
Ralph Castain Nanook
Norbert Eicker JSC

Notes

NOTES

  • Next Meetings and Deadlines
    • PMIX ASC Quarterly Meeting:
      • Q1 2023: January 24 & 26
      • vote in the polls for Q2-4 by Dec 6
    • PMIx ASC Monthly Meeting:
      • Thursday, Dec 8, 2022
  • PMIx v4 Release Update (Ralph/Josh)
  • PMIx v5 Release Update (Ken/Dave)
    • v5.0 planned for 1Q 2023
    • Ken: presented v5 at last 2 quarterly meetings and no major issues so far, few grammatical fixes to be merged.  Plan to have final ratification vote at 2023Q1 meeting.
  • Working Group Updates:
    • Implementation agnostic document: Dave Solt
      • Ralph: Regarding publish/lookup solution discussed previously, there are items from OpenPMIx that need to be ported over to the standard, namely “qualified values” (PMIX_QUALIFIED_VALUE)
      • On track, moving toward new APIs for publish/lookup/unpublish (w/ name change) that would work independently, likely w/ plan to deprecate old interfaces sometime in future.
      • New interfaces plan to get back a handle and then use handle to publish, etc. Questions about best approach for how to best deal with multiple publish items. Example, if publishing foo, bar, baz, should that be allowed in a single publish call or multiple calls.
      • Ralph: Suggestion of passing (on unpublish) to give a NULL meaning all, otherwise unpublish the keys given.
      • Kathryn: does it break model of data store?
      • Ralph: some separation already b/c have a handle and no concept of a handle (i.e., pointer directly to data) and maybe violate some abstractions
      • Question of whether it is easier for user to have to not track keys themselves and have the library track that to simplify (from user perspective).
      • Handle provides the scope for the operations – single vs. multiple handle points, e.g., having key published multiple times and handle helps provide the scoping on unpublish
      • Thought - maybe keep to one handle for one or more keys, but when unpublish can only do all keys (simplest).
      • Suggest - start with that simplest case and allow for change in future, e.g., using attributes for future changes if needed
      • Allow room for expansion in interface in future and be driven by needs
      • Another factor mentioned about a timestamp for publishing multiple keys (e.g., how to break ties)
    • Tools and Dynamic Workflows: Isaías A. Comprés
      • Isaias out, brief update from Ralph
      • Talking about allocation requests and how to deal w/ things like cancellation requests.  Few race conditions raised/discussed.
      • Question about meeting notes, plan to maybe post on WG wiki
      • Next steps seem like to capture discussions across MPI Sesions, MPI FT and PMIx Tools WGs, so need to make sure all pull together.  Good to draft text to get input and find any remaining gaps.
      • Isaias is currently started on implementation of some parts of this work.
      • Ralph plans to start in near future.
      • Lots of interest for scheduler to runtime space
  • ABI Update (Ken/Josh/IAWG)
  • PMIx Standard: Open GitHub Issues and PRs
  • PMIx Governance: Open GitHub Issues and PRs
  • Q: PMIx naming?  The “x” stood for eXascale, but point raise now that since exascale exists, what should be the longer term name, and logo?
Clone this wiki locally