diff --git a/_config.yml b/_config.yml index 6704bb5..aee31fe 100644 --- a/_config.yml +++ b/_config.yml @@ -22,7 +22,7 @@ title: PMIx #email: pmix@example.com description: >- # this means to ignore newlines until "baseurl:" Process Management Interface - Exascale - Copyright 2017-2020 PMIx Community + Copyright 2017-2024 PMIx Community baseurl: "" # the subpath of your site, e.g. /blog url: "" # the base hostname & protocol for your site, e.g. http://example.com #twitter_username: jekyllrb @@ -36,11 +36,11 @@ plugins: header_pages: - standard/index.md # - downloads.md - - privacy.md - publications.md - community.md - contribute.md - meetings/index.md + - privacy.md # Exclude from processing. # The following items will not be processed, by default. diff --git a/community.md b/community.md index a8d6680..2e7b1f6 100644 --- a/community.md +++ b/community.md @@ -10,6 +10,12 @@ of shared concerns for both issues associated with scaling of machines to ever increasing size, and the ability to support the growing wave of innovation in the HPC programming area. +[PMIx Standard](/standard) +=============== + - PMIx Standard (document) + - PMIx RFCs + - Publications/Presentation + The PMIx Standard is governed by an Administrative Steering Committee (ASC) comprised of representatives from a consortium of research, academic, and industrial organizations. The ASC shall consist of one representative from @@ -39,13 +45,34 @@ year. There is no restriction on the number of consecutive terms a given individual may serve – however, it is expected and desirable that the positions rotate amongst the Members. -Current community members include (in no particular order): - -| Intel (Ralph Castain) | IBM (Josh Hursey)** | NVIDIA (Artem Polyakov) | -| LLNL (Kathryn Mohror*, Stephen Herbein) | LANL (Howard Pritchard) | ORNL (Thomas Naughton) | -| Stony Brook Univ (Anthony Curtis) | UnivTenn-Knoxville (Aurelien Bouteiller) | ARM (Dirk Schubert) | -| Altair (Mike Karo) | Perforce (John DelSignore) | +* Co-Chairs + * Aurelien Bouteiller, UTK (2023-2025) (odd year) + * Thomas Naughton, ORNL (2024-2026) (even year) + * Outgoing / Former + * Joshua Hursey, IBM (2024) (even year*interim) + * Kathryn Mohror, LLNL (2022-2023) (even year*) + * Joshua Hursey, IBM (2021-2023) (odd year) + * Kathryn Mohror, LLNL (2020-2022) (even year) + * Joshua Hursey, IBM (2019-2021) (odd year) + * Ralph Castain, Intel (2018-2020) (even year) +* Secretaries + * Norbert Eicker, JSC (2023-2025) (odd year) + * Outgoing / Former + * Thomas Naughton, ORNL (2022-2024) (even year) + * Aurelien Bouteiller, UTK (2021-2023) (odd year) + * Thomas Naughton, ORNL (2020-2022) (even year) + * Stephen Herbein, LLNL (2019-2021) (odd year) +* Release Managers for PMIx standard v5 + * Ken Raffenetti, ANL + * David Solt, IBM +* Release Managers for PMIx standard v4 + * Ralph Castain, Self + * Joshua Hursey, IBM + * Aurelien Bouteiller, UTK +[PMIx Implementation](https://openpmix.github.io) +=========================================== + - Reference implementations + - FAQ + - "How-to" Guides -\* Co-Chair (even year), -\*\* Co-Chair (odd year) diff --git a/contribute.md b/contribute.md index d60d9ae..a7d6142 100644 --- a/contribute.md +++ b/contribute.md @@ -10,7 +10,7 @@ We’d love it! One of the explicit goals of the PMIx community is to actively e The PMIx community has a few focus areas: - - the PMIx Standard. Contributions to the Standard usually take the form of proposed modifications or requests for clarification of one or more portions of the published document. Equally welcome are proposals for new extensions to the Standard. The [PMIx Standard Governance Rules](/uploads/2020/04/pmix_governance-2020-04-15.pdf) describes rules for participation and making changes to the PMIx Standard. The governance document includes instructions for how to raise questions about the standard as well as how to propose changes to the standard. + - the PMIx Standard. Contributions to the Standard usually take the form of proposed modifications or requests for clarification of one or more portions of the published document. Equally welcome are proposals for new extensions to the Standard. The [PMIx Standard Governance Rules](https://github.com/pmix/governance/releases/latest) describes rules for participation and making changes to the PMIx Standard. The governance document includes instructions for how to raise questions about the standard as well as how to propose changes to the standard. - the PMIx Reference Implementations. The latest implementation details can be found on the [OpenPMIx](https://openpmix.github.io) site. diff --git a/features.md b/features.md new file mode 100644 index 0000000..c51fc52 --- /dev/null +++ b/features.md @@ -0,0 +1,19 @@ +--- +layout: page +title: PMIx Standard Features and Roles +permalink: /features +--- + + + +![PMIx Logo Roles](/images/pmix-logo-roles.png 'PMIx Logo Roles') + +This page documents some of the PMIx features and roles that various cluster +subsystems can take, including required as well as desired levels of support. + +- [Fabric Manager](/standard/fabric-manager-roles-and-expectations) +- [Input/Output Forwarding for Tools](/standard/input-output-forwarding-for-tools) +- [Tiered Storage Support](/standard/tiered-storage-support) +- [Logging with PMIx](/standard/logging-with-pmix) +- [PMIx Groups](/standard/pmix-groups) + diff --git a/index.md b/index.md index 9032b6f..b526524 100644 --- a/index.md +++ b/index.md @@ -7,9 +7,20 @@ layout: home ![PMIx Logo](/images/pmix-logo.png "PMIx Logo") - +What is PMIx? +============= +PMIx is an application programming interface standard that provides +libraries and programming models with portable and well-defined access to commonly +needed services in distributed and parallel computing systems. +A typical example of such a service is the portable and scalable exchange of network +addresses to establish communication channels between the processes of a parallel +application or service. +As such, PMIx gives distributed system software providers a better understanding of how +programming models and libraries can interface with and use system-level services. + +More details about [features and roles](/features). [PMIx Standard](/standard) =============== diff --git a/standard/historic.md b/standard/historic.md new file mode 100644 index 0000000..69235ae --- /dev/null +++ b/standard/historic.md @@ -0,0 +1,213 @@ +--- +layout: page +title: PMIx Historical RFC Process +permalink: /standard/historic +--- + +This page contains an historical overview of the RFC standardization process +used during the early stages of the PMIx development. + +**This process is now obsolete, please refer to the [current procedures](/standard) +for standardization. +The rest of this page is verbatim, as it appeared when these procedures were active, +but they are now obsolete.** + +Historical PMIx RFC standardization process +------------------------------------------- + +The PMIx developer community is currently in an early stage – thus, the +process for *extending* the standard is relatively lightweight compared +to more mature communities. In contrast, the process for *modifying* an +existing definition in the standard is intentionally made to be very, +very hard. This serves both to discourage any breaks in backward +compatibility, and to push proposers to scrutinize and scrub their +proposed extensions to ensure they have provided adequate flexibility +for future uses. + +Given the dynamic, fast-moving nature of the community at this time, the +current process for *extending* the standard consists of the following +stages: + +- Create an RFC describing the feature plus any API or attribute + additions +- Create a prototype against the PMIx reference library’s *master* + branch for review (do not commit) +- Present the RFC/prototype at a weekly developer’s teleconference. + This is done to give the community an opportunity to consider + whether or not the proposed extension is acceptable in principal, + and avoids unnecessary expenditure of effort on proposals that are + “dead on arrival” + - If no objection is raised to the concept, then a comment is + added to the RFC noting that it has “Concept Approval” and the + corresponding GitHub label is set + - After two presentations without objection, a comment is added to + the RFC marking it as “Provisionally Accepted”, the + corresponding GitHub label is set, and the proposal is free to + move to the next stage + - If there is an objection or modification request, the proposer + will change the RFC/prototype and present again the next week. + This resets the clock, therefore requiring an additional two + meetings before moving ahead +- Once the RFC/prototype has been Provisionally Accepted, the proposer + is free to merge the prototype into the PMIx reference library’s + *master* branch. The RFC itself is held “open” in the Provisionally + Accepted state +- As the community works with the new code, proposed modifications to + the RFC may be identified. When this occurs, a new commit is made to + the RFC with a link to the PR with the proposed prototype + modifications. Discussion resumes to determine when the prototype + modifications should be merged into the PMIx reference library’s + master branch +- At release time, all Provisionally Accepted RFCs will be + “finalized”. At this time, the proposer will close the PR and make + sure the necessary changes have been made to the PMIx standard + document. + +Note that the above process relies heavily on the level of collaboration +in the current PMIx community. No formal voting process is involved, nor +are there “membership” requirements that must be met before someone has +a voice in the process. This is likely to change as the community grows +and matures. However, the expectation is that the standard will also +have matured by that time, and so a slower, more formal process may be +more appropriate. + +The process for modifying an existing definition in the standard +utilizes the same first three steps of the extension process. However, +the initial presentation of the RFC/prototype must include: + +- a detailed justification for the change; and +- an assessment of the impact of the change on the installed community + +The amount of information provided should reflect the magnitude of the +proposed change. For example, a minor modification in behavior +associated with an existing attribute would require less explanation +than a change to an existing API. In many cases, proposals to modify +definitions are changed to attribute extensions (i.e., the adding of new +attribute definitions). This reflects the PMIx standard’s philosophy of +adding sufficient flexibility (via an array of pmix\_info\_t directives) +to each API to accommodate future additional or modified behaviors +without perturbing the API itself. + +Should the justification prove sufficiently convincing, a Notice of +Impending Change (containing a summary of the proposed change and the +justification) is sent out to the community’s mailing list alerting them +to the proposed modification, and inviting comments. This provides an +opportunity for users and implementors to voice their concerns and +suggest modifications or alternative solutions. Three notices must be +sent prior to a final review of the proposal. + +Assuming no objections are raised, a final review of the proposal – and +its justification – is conducted during a developer’s weekly telecon. +The proposal can be accepted, rejected, or pushed back for modification +at that time. If accepted, the change is made to the standard’s document +– this will include both a description of the change, and the +justification for it. + +### What is Standardized, and What is *Not* Standardized + +No standards body can *require* an implementor to support something in +their standard, and PMIx is no different in that regard. While an +implementor of the PMIx library itself must at least include the +standard PMIx headers and instantiate each function, they are free to +return “not supported” for any function they choose not to implement. + +This also applies to the host environments. Resource managers and other +system management stack components retain the right to decide on support +of a particular function. The PMIx community continues to look at ways +to assist SMS implementors in their decisions by highlighting functions +that are critical to basic application execution (e.g., PMIx\_Get), +while leaving flexibility for tailoring a vendor’s software for their +target market segment. + +One area where this can become more complicated is regarding the +attributes that provide information to the client process and/or control +the behavior of a PMIx standard API. For example, the PMIX\_TIMEOUT +attribute can be used to specify the time (in seconds) before the +requested operation should time out. The intent of this attribute is to +allow the client to avoid “hanging” in a request that takes longer than +the client wishes to wait, or may never return (e.g., a PMIx\_Fence that +a blocked participant never enters). + +If an application (for example) truly relies on the PMIX\_TIMEOUT +attribute in a call to PMIx\_Fence, it should set the **required** flag +in the pmix\_info\_t for that attribute. This informs the library and +its SMS host that it must return an immediate error if this attribute is +not supported. By not setting the flag, the library and SMS host are +allowed to treat the attribute as **optional**, ignoring it if support +is not available. + +It is therefore critical that users and application implementors: + +- consider whether or not a given attribute is required, marking it + accordingly; and +- check the return status on *all* PMIx function calls to ensure + support was present and that the request was accepted. Note that for + non-blocking APIs, a return of PMIX\_SUCCESS only indicates that the + request had no obvious errors and is being processed – the eventual + callback will return the status of the requested operation itself. + +While a PMIx library implementor, or an SMS component server, may choose +to support a particular PMIx API, they are not *required* to support +every attribute that might apply to it. This would pose a significant +barrier to entry for an implementor as there can be a broad range of +applicable attributes to a given API, at least some of which may rarely +be used. The PMIx community is attempting to help differentiate the +attributes by indicating those that are generally used (and therefore, +of higher importance to support) vs those that a “complete +implementation” would support. + +Note that an environment that does not include support for a particular +attribute/API pair is not “incomplete” or of lower quality than one that +does include that support. Vendors must decide where to invest their +time based on the needs of their target markets, and it is perfectly +reasonable for them to perform cost/benefit decisions when considering +what functions and attributes to support. + +The flip side of that statement is also true: Users who find that their +current vendor does not support a function or attribute they require may +raise that concern to their vendor and request that the implementation +be expanded. Alternatively, users may wish to utilize the PMIx Reference +Server as a “shim” between their application and the host environment as +it might provide the desired support until the vendor can respond. +Finally, in the extreme, one can exploit the portability of PMIx-based +application to change vendors. + +PMIx Roadmap +------------ + +The PMIx Standard is evolving fairly rapidly in response to milestones +associated with delivery of next-generation supercomputers. Accordingly, +the timeline is focused towards completing a broad array of features by +the end of 2019. + +PMIx RFCs +--------- + +- v2 RFCs + - [Basic Tool Interaction Mechanism](/standard/RFC/basic-tool-interaction-mechanism) + - [Event Notification](/standard/RFC/event-notification) + - [Modification of PMIx\_Connect/Disconnect](/standard/RFC/modification-of-pmix_connect-disconnect) + - [Flexible Allocation Support](/standard/RFC/flexible-allocation-support) + - [Modify Behavior of PMIx\_Get](/standard/RFC/modify-behavior-of-pmix_get) + - [Extended Tool Interaction Support](/standard/RFC/extended-tool-interaction-support) + - [Refactor Security Support](/standard/RFC/refactor-security-support) + - [Support for Network Interactions](/standard/RFC/support-for-network-interactions) + - [Query Time Remaining in Allocation](/standard/RFC/query-time-remaining-in-allocation) + - [Job Control and Monitoring](/standard/RFC/job-control-and-monitoring) + - [Extend Event Notification](/standard/RFC/extend-event-notification) + - [Expose PMIx Buffer Manipulation Functions](/standard/RFC/expose-pmix-buffer-manipulation-functions) + - [Acquisition of Subsystem Launch Information](/standard/RFC/acquisition-of-subsystem-launch-information) +- v3 RFCs + - [Security Credential Transactions](/standard/RFC/security-credential-transactions) + - [Register Cleanup of Files and Directories](/standard/RFC/register-cleanup-of-files-and-directories) + - [IO Forwarding for Tools and Debuggers (provisionally accepted)](/standard/RFC/io-forwarding-for-tools-and-debuggers) + - [Environmental Parameter Directives for Applications and Launchers](/standard/RFC/envar-directives-for-applications-and-launchers) + - [Coordination Across Programming Models (OpenMP/MPI)](/standard/RFC/coordination-across-programming-models-openmp-mpi) + - [Modify the PMIx buffer manipulation APIs](/standard/RFC/modify-the-pmix-buffer-manipulation-apis) + - [Extended Debugger Support (in progress)](/standard/RFC/extended-debugger-support) + - [DataStore Abstraction Framework (in progress)](/standard/RFC/datastore-abstraction-framework) + - [Extension of PMIx Logging Support](/standard/RFC/extension-of-pmix-logging-support) +- v4 RFCs + - [PMIx Support for Storage Systems (in progress)](/standard/RFC/pmix-support-for-storage-systems) + - [Support for Launching Applications under Debugger Tools (in progress)](/standard/RFC/support-for-launching-applications-under-debugger-tools) + - [PMIx Groups (in progress)](/standard/RFC/pmix-groups-2) diff --git a/standard/index.md b/standard/index.md index 5b243a6..8ac50ef 100644 --- a/standard/index.md +++ b/standard/index.md @@ -4,183 +4,58 @@ title: PMIx Standard permalink: /standard --- -![PMIx Logo Roles](/images/pmix-logo-roles.png 'PMIx Logo Roles') - -Current PMIx Standard ---------------------- +PMIx Standard Releases +---------------------- The following versions of the PMIx Standard document are available: -- Version 2.0 (Sept. 2018) - - [Local website](/uploads/2018/09/pmix-standard.pdf) - - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v2.0) -- Version 2.1 (Dec 2018) - - [Local website](/uploads/2018/12/pmix-standard-2.1.pdf) - - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v2.1) -- Version 2.2 (Feb. 2019) - - [Local website](/uploads/2019/02/pmix-standard-2.2.pdf) - - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v2.2) -- Version 3.0 (Dec 2018) - - [Local website](/uploads/2018/12/pmix-standard-3.0.pdf) - - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v3.0) -- Version 3.1 (Feb 2019) - - [Local website](/uploads/2019/02/pmix-standard-3.1.pdf) - - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v3.1) -- Version 4.0 (Dec 2020) - - [Local website](/uploads/2020/12/pmix-standard-v4.0.pdf) - - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v4.0) -- Version 4.1 (Oct 2021) - - [Local website](/uploads/2021/10/pmix-standard-v4.1.pdf) - - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v4.1) +Direct repository link to the [latest release](https://github.com/pmix/pmix-standard/releases/latest). + - Version 5.0 (May 2023) - [Local website](/uploads/2023/05/pmix-standard-v5.0.pdf) - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v5.0) +- Version 4.2 (May 2024) + - [Local website](/uploads/2024/05/pmix-standard-v4.2.pdf) + - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v4.2) +- Version 4.1 (Oct 2021) + - [Local website](/uploads/2021/10/pmix-standard-v4.1.pdf) + - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v4.1) +- Version 4.0 (Dec 2020) + - [Local website](/uploads/2020/12/pmix-standard-v4.0.pdf) + - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v4.0) +- Version 3.1 (Feb 2019) + - [Local website](/uploads/2019/02/pmix-standard-3.1.pdf) + - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v3.1) +- Version 3.0 (Dec 2018) + - [Local website](/uploads/2018/12/pmix-standard-3.0.pdf) + - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v3.0) +- Version 2.2 (Feb. 2019) + - [Local website](/uploads/2019/02/pmix-standard-2.2.pdf) + - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v2.2) +- Version 2.1 (Dec 2018) + - [Local website](/uploads/2018/12/pmix-standard-2.1.pdf) + - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v2.1) +- Version 2.0 (Sept. 2018) + - [Local website](/uploads/2018/09/pmix-standard.pdf) + - [Repository release](https://github.com/pmix/pmix-standard/releases/tag/v2.0) -Prior *ad hoc* versions of the standard were embodied in the header -files of the corresponding releases of the PMIx Reference -Implementation. These definitions have been superseded by the formal -documents. Each version of the Standard includes information on all -prior versions (e.g., the Version 2.0 document contains the definitions -from Version 1) and clearly marks all additions/changes incorporated -since the last release. Note that the PMIx Community chose not to -release a Version 1 document due to the delay in getting the formal -Standard document completed. +You can track [current developments](/contribute) on the community resources for contributors. -PMIx Standards Process ----------------------- +Expectations attached with the PMIx Standard +-------------------------------------------- -The PMIx developer community is currently in an early stage – thus, the -process for *extending* the standard is relatively lightweight compared -to more mature communities. In contrast, the process for *modifying* an -existing definition in the standard is intentionally made to be very, -very hard. This serves both to discourage any breaks in backward -compatibility, and to push proposers to scrutinize and scrub their -proposed extensions to ensure they have provided adequate flexibility -for future uses. - -Given the dynamic, fast-moving nature of the community at this time, the -current process for *extending* the standard consists of the following -stages: - -- Create an RFC describing the feature plus any API or attribute - additions -- Create a prototype against the PMIx reference library’s *master* - branch for review (do not commit) -- Present the RFC/prototype at a weekly developer’s teleconference. - This is done to give the community an opportunity to consider - whether or not the proposed extension is acceptable in principal, - and avoids unnecessary expenditure of effort on proposals that are - “dead on arrival” - - If no objection is raised to the concept, then a comment is - added to the RFC noting that it has “Concept Approval” and the - corresponding GitHub label is set - - After two presentations without objection, a comment is added to - the RFC marking it as “Provisionally Accepted”, the - corresponding GitHub label is set, and the proposal is free to - move to the next stage - - If there is an objection or modification request, the proposer - will change the RFC/prototype and present again the next week. - This resets the clock, therefore requiring an additional two - meetings before moving ahead -- Once the RFC/prototype has been Provisionally Accepted, the proposer - is free to merge the prototype into the PMIx reference library’s - *master* branch. The RFC itself is held “open” in the Provisionally - Accepted state -- As the community works with the new code, proposed modifications to - the RFC may be identified. When this occurs, a new commit is made to - the RFC with a link to the PR with the proposed prototype - modifications. Discussion resumes to determine when the prototype - modifications should be merged into the PMIx reference library’s - master branch -- At release time, all Provisionally Accepted RFCs will be - “finalized”. At this time, the proposer will close the PR and make - sure the necessary changes have been made to the PMIx standard - document. - -Note that the above process relies heavily on the level of collaboration -in the current PMIx community. No formal voting process is involved, nor -are there “membership” requirements that must be met before someone has -a voice in the process. This is likely to change as the community grows -and matures. However, the expectation is that the standard will also -have matured by that time, and so a slower, more formal process may be -more appropriate. - -The process for modifying an existing definition in the standard -utilizes the same first three steps of the extension process. However, -the initial presentation of the RFC/prototype must include: - -- a detailed justification for the change; and -- an assessment of the impact of the change on the installed community - -The amount of information provided should reflect the magnitude of the -proposed change. For example, a minor modification in behavior -associated with an existing attribute would require less explanation -than a change to an existing API. In many cases, proposals to modify -definitions are changed to attribute extensions (i.e., the adding of new -attribute definitions). This reflects the PMIx standard’s philosophy of -adding sufficient flexibility (via an array of pmix\_info\_t directives) -to each API to accommodate future additional or modified behaviors -without perturbing the API itself. - -Should the justification prove sufficiently convincing, a Notice of -Impending Change (containing a summary of the proposed change and the -justification) is sent out to the community’s mailing list alerting them -to the proposed modification, and inviting comments. This provides an -opportunity for users and implementors to voice their concerns and -suggest modifications or alternative solutions. Three notices must be -sent prior to a final review of the proposal. - -Assuming no objections are raised, a final review of the proposal – and -its justification – is conducted during a developer’s weekly telecon. -The proposal can be accepted, rejected, or pushed back for modification -at that time. If accepted, the change is made to the standard’s document -– this will include both a description of the change, and the -justification for it. - -### What is Standardized, and What is *Not* Standardized - -No standards body can *require* an implementor to support something in -their standard, and PMIx is no different in that regard. While an -implementor of the PMIx library itself must at least include the +While an implementor of the PMIx library itself must at least include the standard PMIx headers and instantiate each function, they are free to -return “not supported” for any function they choose not to implement. +return “not supported” for many function they choose not to implement. This also applies to the host environments. Resource managers and other system management stack components retain the right to decide on support -of a particular function. The PMIx community continues to look at ways -to assist SMS implementors in their decisions by highlighting functions +of a particular function. The PMIx community highlights functions that are critical to basic application execution (e.g., PMIx\_Get), while leaving flexibility for tailoring a vendor’s software for their target market segment. -One area where this can become more complicated is regarding the -attributes that provide information to the client process and/or control -the behavior of a PMIx standard API. For example, the PMIX\_TIMEOUT -attribute can be used to specify the time (in seconds) before the -requested operation should time out. The intent of this attribute is to -allow the client to avoid “hanging” in a request that takes longer than -the client wishes to wait, or may never return (e.g., a PMIx\_Fence that -a blocked participant never enters). - -If an application (for example) truly relies on the PMIX\_TIMEOUT -attribute in a call to PMIx\_Fence, it should set the **required** flag -in the pmix\_info\_t for that attribute. This informs the library and -its SMS host that it must return an immediate error if this attribute is -not supported. By not setting the flag, the library and SMS host are -allowed to treat the attribute as **optional**, ignoring it if support -is not available. - -It is therefore critical that users and application implementors: - -- consider whether or not a given attribute is required, marking it - accordingly; and -- check the return status on *all* PMIx function calls to ensure - support was present and that the request was accepted. Note that for - non-blocking APIs, a return of PMIX\_SUCCESS only indicates that the - request had no obvious errors and is being processed – the eventual - callback will return the status of the requested operation itself. - -While a PMIx library implementor, or an SMS component server, may choose +Similarly, while a PMIx library implementor, or an SMS component server, may choose to support a particular PMIx API, they are not *required* to support every attribute that might apply to it. This would pose a significant barrier to entry for an implementor as there can be a broad range of @@ -206,14 +81,13 @@ it might provide the desired support until the vendor can respond. Finally, in the extreme, one can exploit the portability of PMIx-based application to change vendors. -PMIx Roadmap ------------- +Quick Summary of features per version +------------------------------------- -The PMIx Standard is evolving fairly rapidly in response to milestones -associated with delivery of next-generation supercomputers. Accordingly, -the timeline is focused towards completing a broad array of features by -the end of 2019. The standard is currently defined in 3-4 header files -in each release, as shown below. +This list presents a short summary of features added during different +iterations of the PMIx standard. In recent [revisions of the standard +document](#pmix-standard-releases), a full changelog is provided that +contains a complete list of changes. #### PMIx v1 @@ -296,18 +170,19 @@ integration. #### PMIx v4 -The fourth version of the standard is currently under development. The -full set of new APIs has not yet been defined, but the standard is -expected to be extended to provide schedulers with access to -point-to-point communication cost information along with providing +The fourth version of the standard, v4.0 released in December 2020 focused on +providing schedulers with access to point-to-point communication cost information along with providing general access to network topology graphs, completion of debugger tool support, the initial support for storage requests, and support for the new PMIx Groups concept (in collaboration with the MPI Sessions Working -Group). In addition, Python bindings for the PMIx APIs will be +Group). In addition, Python bindings for the PMIx APIs were introduced in this release. -Development of the Standard can be followed in the v4 RFCs, as listed -below. +v4.1 released October 2022 added a chapter to manage data storage. + +v4.2 still under development will backport some of v5 features +(in particular deprecation of macros and introduction of ABI compatible +functions) and some erratas. #### PMIx v5 @@ -331,57 +206,19 @@ v1.7 document](https://github.com/pmix/governance/releases/tag/v1.7). - PMIx\_Info\_list\_convert - PMIx\_Info\_list\_release -Roles and Responsibilities --------------------------- - -Provides guidance on the expectations PMIx places on various cluster -subsystems, including required as well as desired levels of support. - -- [Fabric Manager](/standard/fabric-manager-roles-and-expectations) -- [Input/Output Forwarding for Tools](/standard/input-output-forwarding-for-tools) -- [Tiered Storage Support](/standard/tiered-storage-support) -- [Logging with PMIx](/standard/logging-with-pmix) -- [PMIx Groups](/standard/pmix-groups) - -PMIx RFCs ---------- - -- v2 RFCs - - [Basic Tool Interaction Mechanism](/standard/RFC/basic-tool-interaction-mechanism) - - [Event Notification](/standard/RFC/event-notification) - - [Modification of PMIx\_Connect/Disconnect](/standard/RFC/modification-of-pmix_connect-disconnect) - - [Flexible Allocation Support](/standard/RFC/flexible-allocation-support) - - [Modify Behavior of PMIx\_Get](/standard/RFC/modify-behavior-of-pmix_get) - - [Extended Tool Interaction Support](/standard/RFC/extended-tool-interaction-support) - - [Refactor Security Support](/standard/RFC/refactor-security-support) - - [Support for Network Interactions](/standard/RFC/support-for-network-interactions) - - [Query Time Remaining in Allocation](/standard/RFC/query-time-remaining-in-allocation) - - [Job Control and Monitoring](/standard/RFC/job-control-and-monitoring) - - [Extend Event Notification](/standard/RFC/extend-event-notification) - - [Expose PMIx Buffer Manipulation Functions](/standard/RFC/expose-pmix-buffer-manipulation-functions) - - [Acquisition of Subsystem Launch Information](/standard/RFC/acquisition-of-subsystem-launch-information) -- v3 RFCs - - [Security Credential Transactions](/standard/RFC/security-credential-transactions) - - [Register Cleanup of Files and Directories](/standard/RFC/register-cleanup-of-files-and-directories) - - [IO Forwarding for Tools and Debuggers (provisionally accepted)](/standard/RFC/io-forwarding-for-tools-and-debuggers) - - [Environmental Parameter Directives for Applications and Launchers](/standard/RFC/envar-directives-for-applications-and-launchers) - - [Coordination Across Programming Models (OpenMP/MPI)](/standard/RFC/coordination-across-programming-models-openmp-mpi) - - [Modify the PMIx buffer manipulation APIs](/standard/RFC/modify-the-pmix-buffer-manipulation-apis) - - [Extended Debugger Support (in progress)](/standard/RFC/extended-debugger-support) - - [DataStore Abstraction Framework (in progress)](/standard/RFC/datastore-abstraction-framework) - - [Extension of PMIx Logging Support](/standard/RFC/extension-of-pmix-logging-support) -- v4 RFCs - - [PMIx Support for Storage Systems (in progress)](/standard/RFC/pmix-support-for-storage-systems) - - [Support for Launching Applications under Debugger Tools (in progress)](/standard/RFC/support-for-launching-applications-under-debugger-tools) - - [PMIx Groups (in progress)](/standard/RFC/pmix-groups-2) -- [v5 Pull Requests](https://github.com/pmix/pmix-standard/milestone/6?closed=1) - -PMIx Presentations ------------------- - -- Debuggers, Tools, and Next-Gen Fabric - [PDF](/uploads/2018/11/PMIxF2F.pdf) - [PPX](https://www.slideshare.net/rcastain/pmix-debuggers-and-fabric-support) -- SC18 BoF [PDF](/uploads/2018/11/PMIx-BoF-2018.pdf) - [PPX](https://www.slideshare.net/rcastain/sc18-bof-presentation) +Historical Standardization Process +---------------------------------- + +Prior *ad hoc* versions of the standard were embodied in the header +files of the corresponding releases of the PMIx Reference +Implementation. These definitions have been superseded by the formal +documents. Each version of the Standard includes information on all +prior versions (e.g., the Version 2.0 document contains the definitions +from Version 1) and clearly marks all additions/changes incorporated +since the last release. Note that the PMIx Community chose not to +release a Version 1 document due to the delay in getting the formal +Standard document completed. + +You can refer to the [historical RFCs standardization process manifesto](/standard/historic) +to review early standardization practices. diff --git a/uploads/2024/05/pmix-standard-v4.2.pdf b/uploads/2024/05/pmix-standard-v4.2.pdf new file mode 100644 index 0000000..64cfb37 Binary files /dev/null and b/uploads/2024/05/pmix-standard-v4.2.pdf differ