Repository navigation
prted: do not register a tool's namespace with PMIx - #2880
Merged
Merged
Conversation
PRRTE knows nothing of a tool's job beyond what the tool sends: the job size, app and proc info it registered for each tool were guesses, and the tool library sets the same well-known values for itself. PMIx is to treat a namespace the host registers while it decides on a tool that named itself as a job of the host's, and refuse the tool with PMIX_ERR_EXISTS, so that such a tool cannot join a job of that name that the host starts meanwhile. Registering the tool's own namespace there would get every prun and pterm refused. prte_pmix_server_register_tool() now only builds the tool's job object, which PRRTE needs to retire the tool's job when it leaves, and both callers answer the tool at once. Nothing in it needs a PMIx server any more, so its unit test covers the whole of it, including a tool that sent no command line, and the todo entry for that goes. Signed-off-by: Ralph Castain <rhc@pmix.org>
rhc54
added a commit
to openpmix/openpmix
that referenced
this pull request
Nov 2, 2026
- A tool or launcher acts on events, key deletions and store updates (tags 0, 4 and 5) only from a server of its own, as it does for IOF. A peer a tool makes its server with PMIx_tool_set_server counts as one. - A call joining a group construct still collecting must be of the same operation and, when the call that began it listed every participant, one of them. - An event at PMIX_RANGE_NAMESPACE with no targets is delivered live to the source's namespace only, as cached-event replay already does. - An event from a client carrying more than one PMIX_EVENT_CUSTOM_RANGE is refused with PMIX_ERR_BAD_PARAM. - A client's monitor may raise PMIX_SUCCESS (the monitor's own code), a monitor code, or a user code - one beyond PMIX_EXTERNAL_ERR_BASE, or a positive one; other codes are refused with PMIX_ERR_BAD_PARAM. A monitor's alert carries its ID, its settings and the heartbeats or checks missed, under two new attributes, PMIX_MONITOR_HEARTBEAT_MISSED and PMIX_MONITOR_FILE_MISSED. - An IOF deregistration from a peer other than the one that registered the request is answered PMIX_ERR_NOT_FOUND. - A commit carrying a "pmix" key other than PMIX_QUALIFIED_VALUE is refused whole, before anything in it is stored. PMIx_Put and the commit share one helper for the rule, pmix_key_may_be_put. - A get qualified by PMIX_SESSION_ID answers about the session named and leaves the job in its own session; the job_data_changed record that went with the old behaviour is removed. - A tool that named itself is refused with PMIX_ERR_EXISTS when the host registers a namespace of that name while deciding on the tool, and when it names a rank the host did not register in a namespace the host did. docs/hosts says not to register such a tool's namespace; PRRTE no longer does (openpmix/prrte#2880). Each change has a unit test. Signed-off-by: Ralph Castain <rhc@pmix.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PRRTE registered a namespace with PMIx for every tool that connected (
prte_pmix_server_register_tool): job size, apps, node and proc info. These are guesses - PRRTE knows nothing of a tool's job beyond what the tool sends - and the tool library sets the same well-known values for itself (pmix_tool_init_info).A companion PMIx change refuses a tool that named itself, with
PMIX_ERR_EXISTS, when the host registers a namespace of that name while it decides on the tool. Such a namespace can only be a job of the host's that took the name meanwhile, and the tool joining it would turn the job's own processes away. With that change, PRRTE's registration of the tool's own namespace would get everyprunandptermrefused. So this PR stops registering it.prte_pmix_server_register_tool()now only builds the tool's job object, which PRRTE uses to retire the tool's job when it leaves. Both callers, the master's and the relay's, answer the tool at once.test_tool_registrationnow covers all of it, including a tool that sent no command line. Thedocs/todo.rstentry for that is removed.This must merge before the PMIx change. PMIx CI builds PRRTE master, and with today's PRRTE the new PMIx refuses
prunandpterm(PMIX_ERR_EXISTS).Tested on macOS, against both today's PMIx master and the PMIx change:
prun -n 2 hostnameandptermworks.