Define mission statement and core functionalities

[gvallee]

Overview

Having a mission statement as well as a clear definition of what composes the core of the PMIx standard would help define what is the PMIx standard, what is in it and what could be added to it.

This issue is not meant to say that we should have a mission statement and a definition of core functions/attributes but rather drive the discussion and try to ultimately have consensus within the group.

Motivation

The following questions periodically are raised during discussions:

• Should we aim at limiting the size of the standard and if so, how big the standard should be?
• What APIs should be in stable class (see issue #179)?
• Do we want to have a set of APIs and attributes that implementations must implement and if so how do decide what would that be?

The goal of this issue is not to answer these questions (we may end up opening separate issue for these questions), it instead focuses on the idea of defining a mission statement and the definition of what would be the core of the PMIx standard to help drive the future discussions aiming at answering these questions.

Discussion Items

The following points were discussed so far to define the mission statement and what should be the core of the PMIx standard.

Mission statement

• Underlying question 1: Do we need to control/limit the size of the standard?

Having a clear mission statement would be a good step at ensuring the standard is of the "right size", making it easier to implementors to support PMIx. In other words, having a clear mission statement would help us ensure that the standard only includes what is necessary. Optional feature could still be available in implementations and/or ("and/or" needs to be discussed) in the "lower-class" of the standard (see issue #179).

However, it may limit the openness of the community, each group in the community having a different set of goals and a different mission. Therefore, having a restrictive mission statement would prohibit contributions from new group. Instead, we may want to keep the current approach of giving the opportunity to implementors to not implement functions and/or attributes. In other words, implementors are free to decide which functions and attributes they provide. How do we then identify the set of functions and attributes is required at a given time (e.g., for procurement)? Through use cases (e.g., system X must provide an PMIx implementation supporting MPI wire-up)?

• Underlying question 2: Can we have a dynamic/flexible mission statement?

PMIx aims at providing a standardized set of interfaces and attributed
that support application interactions with the system management stack,
including system subsystem-to-subsystem interactions that help enable
application-driven workflow orchestration. Thus, the standard provides an
interface by which the applications can request a particular operation (e.g.,
"position this file into a nearby cache") and an abstracted interface by
which the resource manager can pass that request on to the storage
system. This allows both the application and the SMS to work with
abstracted interfaces, thereby reducing the amount of target-specific
code they have to write/support.

By being dynamic/flexible, it is possible to revisit when new use cases are considered by the standardization group. It is in fact the approach that was implemented so far and one of the reason of its success. We may not want to move away from this. What would be the down side of having a very flexible mission statement? Is it only related to the first point, i.e., the size of the standard?

Standard core

Underlying question 1: Do we need a "standard core" that would be required for implementations to provide?

Defining a core of the standard as the set of functions and attributes that are stable and required to be provided by all implementations, would allow implementors to precisely know what needs to be implemented, while not having to implement the entire standard. However, we cannot require an environment-specific implementation to implement APIs and attributes that have nothing to do with their target market without the experienced risk of community members just move away for the standard all-together. ** This is a serious issue that prevent us from defining a core set of functionalities and attributes as being required from all implementations. But do we all agree on this? Or is there a need for more discussions?**

The notion of core functions and attributes might still be beneficial to identify at first which functions and attributes would be included in a "stable" class see issue #179). Maybe a good way to think about it is to consider the core as the intersection of the all the functions and attributes from use cases that are a priority for the standardization group. Use cases here are not all possible contexts where PMIx is or could be used, but the use cases that the standardization group want to focus on and for which the group wants to provide a clear and stable standard. However if we consider the core as the intersection of the functions and attributes for the use cases the standardization group cares about, it might take a long time to define what it is. Is the standardization group willing to wait?