Skip to content

Meeting 2022 12 08

Jump to bottom
Thomas Naughton edited this page Dec 8, 2022 · 3 revisions

Agenda

  • Next Meetings and Deadlines
    • PMIX ASC Quarterly Meeting:
      • Q1 2023: January 24 & 26
        • Dec. 27 : Announcement Deadline
        • Jan. 10 : Agenda Finalization
      • Vote in the polls for Q2-4 by Dec 6
PMIx ASC 1Q 2023 Meeting (Format: Virtual)
 * Jan. 24 & 26 (10 am - 1 pm US Central)
 * Previously determined

PMIx ASC 2Q 2023 Meeting (Format: Virtual)
 * May 9 & 11, 2023 (10 am - 1 pm US Central)

PMIx ASC 3Q 2023 Meeting (Format: Virtual)
 * July 18 & 20, 2023 (10 am - 1 pm US Central)

PMIx ASC 4Q 2023 Meeting (Format: TBD - likely virtual)
 * Oct. 17 & 19, 2023 (10 am - 1 pm US Central)

Attendance

Person Institution
Josh Hursey IBM
Michael Karo Altair
Ralph Castain Nanook
Thomas Naughton ORNL
Kathryn Mohror LLNL
Norbert Eicker JSC
David Solt IBM
Ken Raffenetti ANL

Notes

  • Next Meetings and Deadlines
    • PMIX ASC Quarterly Meeting:
      • Q1 2023: January 24 & 26
    • PMIx ASC 2023 Meetings
    • PMIx ASC Monthly Meeting:
      • January monthly meeting canceled for the Q1
  • PMIx v4 Release Update (Ralph/Josh)
    • v4.2 planned for release 1Q 2023
    • No new updates
  • PMIx v5 Release Update (Ken/Dave)
    • v5.0 planned for 1Q 2023
    • No new updates
  • Working Group Updates:
    • Implementation agnostic document: Dave Solt
      • Brief, see publish/lookup discussion later this meeting
    • Tools and Dynamic Workflows: Isaías A. Comprés
      • Ralph: mention of slurm integrations/updates, new APIs for allocation controls for changes related to sessions with updates to openpmix/prte repos with Tools WG working along
  • Publish/Lookup Chapter Discussion
    • https://github.com/pmix/pmix-standard/pull/398
    • Review PMIx_Publish_datastore updates
    • Intend to have an epoch/timestamp to order keys in a publish
    • Suggestion: may want to add AtoI note that intent is to not guarantee fine grained ordering, but instead a general ordering.
    • Discussion: Need to be able to have two processes be able to publish/unpublish a piece of data.  The current text is thinking that this is not allowed (i.e., only publisher can unpub).  If allow other processes to unpublish, then maybe handle is not good approach.  Another idea was to send a request to owner of item to unpublish instead of secondary process directly modifying (unpublishing).
    • Discussion: Thought that if pass back sequence number, maybe that’s a “handle”,  but that could be what’s used to do say an unpublish of key X with timestamp Y.  Who maintains the handle (e.g., sequence number owned by datastore, runtime, etc.).  Intent being to clarify in the standard what are the responsibility for maintaining/managing the “handle”.
    • Discussion: At end, thought was maybe timestamp is sufficient and not need to introduce the concept of a handle (new construction to standard).  Think about just publishing key Foo with timestamp1, Bar with timestamp2, etc.  Maybe even keep the handle, but not have it be opaque.  Still have to decide who maintains it, but when not opaque would have structure to know how to transfer (e.g., between server and runtime).
    • Question: What is the tuple for the datastore? e.g., {key/seq#/userid}
      • key/seq# and procid that published it (question if need procid if have seq#), also have userid/groupid.
      • So yes, seems that you’d have {key/procid/userid/groupid/seq#} and then use the seq# for sorting, specific versioning & ordering
    • Question: Are we no longer have restriction that the process is only one that can unpublish – just have to be in the same userid/groupid?
      • Maybe, that’s how it has been thus far.  But could adjust this and maybe even add an attribute (e.g., “exclusive bit”) to restrict who can publish/unpublish.
      • There are already some attributes that are similar, e.g., auto-unpublish after first access.  This avoids additional acknowledgement phases to remove things after they’ve been used.
      • Could be fine to have the publisher control who can delete and when.
      • Maybe look closer at the handle datastructure, maybe make it more transferable (e.g., not opaque).
    • Question: At unpublish time, do we want to only unpublish for one seq# at a time, or a list (key/seq#, key/seq#, etc.)?
      • Maybe could use some wildcarding for the seq# part
      • But seems like will need a list
    • Question: How do you want to return status for unpublish?
      • Ask for keyA v3, keyB v5 – but can not return keyBv5 b/c already deleted, what error status do you want returned? Similarly when dealing w/ wildcards.
      • Already have this “partially successful” in query results, but will need to consider in this scenario too
      • Also what happens if you ask to unpublish something not allowed to unpub, do you want a warning/error status for this?
  • PMIx Standard: Open GitHub Issues and PRs
    • #2844 - macros for symmetry related to PMIX_CPUSET_DESTRUCT
      • https://github.com/openpmix/openpmix/pull/2844
      • have a construct/destruct functions (symbols) but do not have them both as macros
      • Question raised about whether to have full symmetry for all functions to allow for using “all macros” or “all functions” but avoid having a mix
      • Suggestion: Do all as symbols (functions) to aid with ABI, etc.
      • Seems that preference for functions, if want to use macros that call corresponding functions for historical purposes, but generally prefer functions.
      • Okay, will need to update the standard for updating this point.  Josh will take action on this item (maybe for 4.2 inclusion).
  • PMIx Governance: Open GitHub Issues and PRs

Home

Working Groups

Events

Helpful How To...

ASC Quarterly Meetings

ASC Monthly Meetings

Clone this wiki locally