-
Notifications
You must be signed in to change notification settings - Fork 22
ASC Q1 2025 Meeting
Aurelien Bouteiller edited this page Jan 29, 2025
·
8 revisions
- Date: Jan. 28 & 30, 2024
- Time: 10 am - 1 pm US Central Daylight Time each day
- Location: Virtual Meeting. Zoom Info (link also in the Active notes Google doc below)
- Active Notes Link: Google Doc - Please add your name and affiliation.
- Governance Document [latest]
- Voting Link
This meeting has a floating agenda with specific synchronization points to keep us on track. Rough time estimates are provided per agenda item, and the co-chairs plan to cover the topics in the order seen below. However, since some agenda items will take longer/shorter than anticipated, an exact start/end timing is not guaranteed, and some items may float to the second day. If you cannot attend the full meeting and are presenting, please let the co-chairs know, and we can plan accordingly.
| Start | End | Topic |
|---|---|---|
| 10:00 am | 10:05 am | Gathering (--) |
| 10:05 am | 10:10 am | Roll Call (We will start roll call promptly at this time) |
| 10:10 am | 11:30 am | Discussion of agenda items |
| 11:30 am | 11:45 am | Break |
| 11:45 am | 1:00 pm | Discussion of agenda items |
| Start | End | Topic |
|---|---|---|
| 10:00 am | 10:05 am | Gathering (--) |
| 10:05 am | 11:30 am | Discussion of agenda items |
| 11:30 am | 11:50 am | Voting and Break Voting Link |
| 11:50 am | 12:45 am | Administrative and Working Group agenda items |
| 12:45 am | 1:00 pm | Closing discussion and wrap up |
-
Administrative announcement
- Calendar FY25
- ASC 25Q2: May 6, 8
- ASC 25Q3: July 15, 17
- ASC 25Q4: Oct 14, 16
- Open PMIx ASC position:
- co-secretary: Open
- co-chair: A. Bouteiller reaching end-of-term; elections to be held in 25Q1 for 2025-2026 term
- Calendar FY25
-
Officer nominations:
- Aurelien Bouteiller (co-chair 2025-2026)
-
Working Groups Updates:
- IAWG (Dave Solt)
- Dynamic/Tools (Isaias Compres)
- Call for new WGs?
-
Release planning
-
Governance Votes
- co-chair 2025-2026
-
Governance PRs up for a Second Vote:
- None
-
Governance PRs up for a Reading and First Vote:
- None
-
PMIx Standard PRs up for a Reading (Provisional):
- None
-
PMIx Standard PRs up for a Reading (Errata):
- None
-
PMIx Standard PRs up for a Second Vote:
- None
-
PMIx Standard PRs up for a Reading and First Vote:
- None
-
Plenary discussion items
- Editorial PRs
- Stalled PRs?
- New PRs
- Governance: What to do about provisional API/ABI?
- Other/Open discussion
| Person | Institution | Day 1 | Day 2 |
|---|---|---|---|
| Aurelien Bouteiller | UTK | yes | |
| Norbert Eicker | JSC | yes | |
| Ralph Castain | yes | ||
| Isaias Compres | TUM | yes | |
| Howard Pritchard | LANL | yes | |
| Kathryn Mohror | LLNL | yes | |
| Thomas Naughton | ORNL | yes |
-
Officer nominations:
- Aurelien Bouteiller (co-chair 2025-2026)
-
Working Groups Updates:
- IAWG (Dave Solt)
- WG continues to work on the example use-case codes, they are getting close to ready for release
- tool/server example code: https://gist.github.com/dsolt/3654060204b8e9251c2e4700bece97f5
- wireup example code:
- pmix-examples mockup website: https://pmix-examples.readthedocs.io/en/latest/
- WG continues to work on the example use-case codes, they are getting close to ready for release
- Dynamic/Tools (Isaias Compres)
- Looking at the simplified scheduling environment, using Python-based scheduler (external to the core impl.)
- Goal remains to have a small and simple research scheduler not to compete with production (e.g. slurm) schedulers
- Think about if/how this effort can be shown in a use-case/documentation code
- Next WG meeting is first wed. of march
- Call for new WGs?
- None
- IAWG (Dave Solt)
-
Release planning
- 5.1
- https://github.com/pmix/pmix-standard/milestone/10
- Some value in pursuing a new version to eliminate ambiguity between v4.2/v5.0 (see PR#514 changelog items for errors corrected in v5.1)
- Need to review other items and drift items (note openpmix may deprecate some things, which could eliminate some items from this “drift” list). Would be good to dedicate time to triage the drift list and identify the what should remain and what would fit into v5.1 or future.
- In relation to the provisional promotion, we may consider 6.0 instead of 5.1 (required for ABI/procedural purposes when promoting provisional attributes/APIs). This is what the ASC prefers according to our discussions.
- Note: Item for next monthly agenda, make an issue with the list of provisionals to promote and how difficult/controversial these would be. After our review it is expected that the vast majority are noncontroversial, a couple may require review, and we will defer provisional promotion of the storage chapter to a later version (when implemented).
- 5.1
-
Plenary discussion items
- Editorial PRs
- https://github.com/pmix/pmix-standard/pull/449 (merged) no issue found after review
- https://github.com/pmix/pmix-standard/pull/500 (merged) no issue found after review
- https://github.com/pmix/pmix-standard/pull/514 (ready to merge) minor changes requested, ready to merge
- Stalled PRs?
- https://github.com/pmix/pmix-standard/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Aopen+label%3A%22Pushed+Back%22 second PR about statistic collecting could be revived if interested party wants to take it on, main focus will remain on documenting use-cases and doing cleanup release for now
- New PRs
- https://github.com/pmix/pmix-standard/pull/516: ready to announce for official reading at ASC 25Q2
- Governance: What to do about provisional API/ABI?
- We reviewed provisional APIs/attributes (most introduced in 5.0) and are considering the idea of promoting them to stable. See discussion above for 5.1 planning about findings.
- Other/Open discussion
- We had a discussion about error code granularity, and how many error codes and specificity we want to have in error reporting. We used the example of the issue with resolve peers and error codes: if we can’t find the peer, should we have new errors, should we return success with an empty list? Discussion on Open PMIx Problems with PMIx_Resolve_peers and spawned processes
- In this case we found that returning success and an empty list would be adequate, but having more granularity to understand why the outcome is not as expected can be useful in some cases. We may consider adding necessary query mechanisms on an as-needed basis (May not always be errors, as illustrated with the resolve peer example).
- Brief review of drift items (?)
- https://github.com/openpmix/pmix-tests/actions
- Triaged items are entered into Issues list with the “Drift:” prefix
- Note: Not all items identified in scans are needed (e.g., prototyping in openpmix) but once confirmed as gap a new ticket is created.
- Editorial PRs
- CANCELLED
- Vote results
- TBA