Checklist for "stable" landing point

[rhc54]

With the project winding down, it is time to define a stable landing point where we can leave it for those wanting to use it. This means:

• removing all stale code, particularly components that aren't actively used
• collapsing frameworks into single code directories where multiple variations are not required (e.g., rtc)
• reducing complexity wherever possible

We'll keep a checklist here as we work thru the process - will culminate in a new PRRTE v4 release series

Code pruning and correction

• Remove "likwid" mapper - never implemented
• Remove "slurm" and "mpich" personalities - never fully implemented nor used
• Collapse "rtc" framework
• Collapse "oob" framework - consolidate the messaging system and refactor it
• Remove "psched" tool - being replaced by external "dynasched" Python project
• Revamp tool system - replace individual tools (e.g., "pterm") with options to "prte" itself to remove conflicts with other packages, need to design this as we must retain "prterun" and "prun" as separate cmds
• Resolve "permanent" solution to the Slurm plm problem - use new launcher lib if it becomes available, otherwise may need to remove envar support for the internal "srun" cmd line options (see also: Slurm integration #1974)
• Raise min HWLOC version to 2.1.0
• Fix the "show-help" mess by clarifying the source of what gets installed - either in the top-level src/doc/show_help directory, or in the localized ones
• Resolve known pending issues
  • add-hostfile not working on parallel prun commands #1773
  • PMIx Process Group construction with spawend processes on multiple nodes crashes (version 4.2.9) openpmix#3360 (cross-project)
  • pterm conflicts with putty #1836
  • PLM:SLURM doesn't work right for HPE Sling Shot when VNI enabled #2004
• Make one last "production" release - v3.0.7

Enhancements

• Add PRRTE-internal resiliency support - recover connections to grandparents when parent connection is lost, restore parent connection if/when parent returns, number collective messages to ensure replay when necessary

Scheduler integration

• Resolve question of moving scheduler integration support into separate branch
• Complete node extension support for adding nodes on-the-fly
• Complete session directive support - e.g., session/job preemption

[naughtont3]

* [ ]  Resolve "permanent" solution to the Slurm plm problem - use new launcher lib _if_ it becomes available, otherwise may need to remove envar support for the internal "srun" cmd line options

Quick follow-up after 3oct2024 teleconf, I was mistaken and the SLURM_VERSION is not exported as an envvar within the allocation. Appears you must go through one of the utilities (e.g., srun --version, scontrol show config | grep SLURM_VERSION).

shell: $ srun --version
slurm 24.05.2
shell: $ scontrol show config | grep SLURM_VERSION
SLURM_VERSION           = 24.05.2
shell: $ echo $SLURM_VERSION

shell: $

[rhc54]

If you just get an allocation (salloc and no srun) is there anything you can see that might give us a hint as to version, even if it doesn't give us a direct value?

[naughtont3]

Unfortunately, i do not see anything that would give an indication (salloc and then env | grep SLURM).

[rhc54]

The "oob collapse" has been completed - see #2035

[edgargabriel]

@rhc54 Is the fix of open-mpi/ompi#12682 already in as well?

[rhc54]

Yes - everything is caught up. I have one thing still in the queue, but it's being tracked over in the PMIx repo. Otherwise, everything still needing attention is listed above, and anything else is done. The fix you ask about is also in the release branch awaiting update over in OMPI.