-
Notifications
You must be signed in to change notification settings - Fork 22
Meeting 2022 03 10
- Date: March 10, 2022
- Time: 11 am - Noon US Central Daylight Time
- Location: Virtual Meeting. WebEx information: https://recaptcha.open-mpi.org/pmix-std-recaptcha/
- Active Notes Link: Google Doc - Please add your name and affiliation.
- Next Meetings and Deadlines
- PMIx ASC Monthly Meeting:
- Thursday, April 14, 2022 (No Feb monthly meeting)
- PMIX ASC Quarterly Meeting: May 10 and 12, 2022
- Announcement Deadline: April 12, 2022
- Agenda Finalization: April 26, 2022
- PMIx ASC Monthly Meeting:
- PMIx v4 Release Update (Ralph/Josh)
- v4.2 planned for Mid/Late 2022 (as needed)
- PMIx v5 Release Update (Ken/Dave)
- Working Group Updates:
- Implementation agnostic document: Dave Solt
- Tools: Isaías A. Comprés
- Dynamic workflows: Justin Wozniak
- ABI Update (Ken/Josh/IAWG)
- https://github.com/pmix/pmix-standard/issues/365 (general issue)
- PMIx Standard: Open GitHub Issues and PRs
- PMIx Governance: Open GitHub Issues and PRs
Person | Institution |
---|---|
Josh Hursey | IBM |
Kathryn Mohror | LLNL |
Ralph Castain | Nanook |
Michael Karo | Altair |
Norbert Eicker | JSC |
Isaias Compres | TUM |
Thomas Naughton | ORNL |
-
PMIx v4 Release Update
- Merged all PRs, few reviews needed on “Sync” tickets for v4 and v5 items
- No known release pressure
- Q: What about release to sync with Open MPI v5 release?
- Will check on Open MPI v5 timeline to see if should align PMIx v4 standard release. Also some debugger/tools cases may have interest w/ some items in v4 coming out in near term.
-
PMIx v5 Release update
- No questions
-
Working Group updates
- Implementation agnostic
- working through some cleanups/use case items, and other half is time on ABI
- pmix-abi repo made public (https://github.com/pmix/pmix-abi)
- Tools
- Busy lately, standing up a prototyping environment for bulk job/tasks.
- Working on set of slurm plugins to support use cases. Will evaluate if further pmix interfaces needed, but focus currently on prototyping.
- Moved meetings to monthly schedule
- Interested at looking into process tables, maybe relates to ABI discussion
- After research work progresses, long-term plan is to open artifacts from slurm as public/community plugins
- Dynamic workflows
- Problem with scheduling / meeting invite. Will check w/ Justin
- Josh working on some items involving Kubernetes/containers with PMIx aspects. Working with RedHat on this and as progresses may offer updates at future ASC meeting.
- Implementation agnostic
-
ABI Discussions
-
Summary ticket created https://github.com/pmix/pmix-standard/issues/365
-
Includes status, pointers to open PRs, etc.
-
Regarding
pmix_proc_t
andpmix_key_t
, summary is that deemed too disruptive at current and not intend to change these items. -
Some discussion about alternate formats for storing the process-table. Possibly need to have different layouts for these tables (implementation). Distinct form the individual
pmix_proc_t
data structure itself. Possible concern in context of ABI regarding the growth of large process tables due to size of data structure. -
Discussion was to possibly create an alternate proc info structure, e.g., sparse or reduced info w/o redundant/extraneious items to reduce size. The idea being that you could create this alternate proc struct and avoid breaking things, instead provide the user this alternate structure,e,g. Query on nspace and return info w/o tons of redundant nspace as
proc_slimmer_foo_t
-
Discussion on how to deal w/ macros and dependent functions, some possibly not part of the pmix spec (e.g., argv processing like
PMIX_ARGV_COUNT
/pmix_argv_count()
). Suggestion maybe adjust name to include "pmix_abi_” to make it clear/distinct. -
Discussion on versioning w/ ABI and compatibility of PMIx specification version. Looking for strong use-case to drive this point.
-
Possibly debuggers have this need?
-
One example would be if a function signature was version specific, you could query for version to understand proper signature to use. But in practice will try to avoid this behavior (change function signature w/o changing function name).
-
The provisional APIs are a possible exception to this practice, maybe those could “evolve” a bit w/o having to create an entirely new name. And in those cases it would benefit from the symbol versioning.
-
Note dlvsym() might be useful here. Provides a version string on the symbols.
-
Possibly another way to cope with this request by using this GNU dlvsym() instead of having it in PMIx itself. Some concern over portability of this dlvsym capability in other toolchains.
-
TODO - create a simple test case to exercise this functionality across different compiler toolchains
-
If restricted to GCC, maybe too limiting to be interesting.
-
Other idea was to have the
PMIx_Get_ABI_version
to get at the version info.
-