Skip to content

Meeting 2019 08 16

Jump to bottom
Josh Hursey edited this page Aug 16, 2019 · 1 revision

Agenda

Notes

        Joshua Hursey (IBM)
	Ralph Castain (Intel)
	Michael Karo (Altair)
	Thomas Naughton (ORNL)
	Kathryn Mohror (LLNL)
	Ken Raffenetti (ANL)
	Stephen Herbein (LLNL)
	David Solt (IBM)
	Geoffroy Vallee (Sylabs Inc)
	Swaroop Pophale (ORNL)
  • (Dave) Working group: Implementation agnostic document
    • Links to the current Chapter 1 changes:
    • Trying to broaden language to make it not specifically HPC focused.
    • Target to have a good draft of Chapter 1 in a week or two
    • How should folks provide comment?
    • Discussion: Document has suggestion that the PMIx library becomes more of a ‘doer’ than a ‘messenger’.
      • This needs some more discussion in the working group. Slotted for next week.
  • Working group mailing lists. Is this helpful?
    • Yes this would be helpful for traffic specific to the working groups without bothing the whole list.
    • (Josh) Setup a mailing list for each group
  • (Stephen) Working group: Slicing/Grouping of functionality
    • Wrapped up review of RFCs in the repo (and PRs)
      • Recording interfaces, attributes, use cases
    • Now ‘flipping’ the model to classify sets of use cases and filling out those items as GitHub Issues using the “Use Case” template.
    • Also doing a “gap analysis” of those interfaces/attributes in the standard that were not covered by the RFCs (e.g., PMIx_Get). Also trying to make sure they are not missing any use cases.
    • Once that is complete then will circulate the set to the list to see if there is any use case or protocol detail missing.
    • Discussion: Feedback on reviewers of newer RFCs is that they liked functional chapters to make it easier to see the interfaces and attributes specific to that function.
      • Question about what to do about cross-cutting attributes (e.g., timeout).
        • Do we duplicate them, or have a central reference with cross-referencing.
      • Question about items that do not fit nicely in a functional unit (e.g., datatype packing/unpacking).
    • Ralph is starting work on a ‘how to’ chapter for debuggers/tools
      • Swaroop is working on some of this in the working group. Will work together on pushing this forward.
      • Describing the method/protocol for using the API. This would be good to have documented in the standard. Maybe as a separate chapter.
    • No meeting for this working group over the next two weeks.
      • Will create a mailing list to collaborate.
  • ASC Quarterly Meeting
  • Discussion: State of current APIs/Attributes (provisional/stable)
    • Suggestion: v4 interface to be marked as ‘stable’ in the v5.
      • Author of v4 RFC can suggest that an interface be initially marked as “provisional”.
    • Should we delay the transition from v4 to v5?
      • Some new RFCs (i.e., storage) might be best labeled as “provisional” since they are just starting development/refinement of those interfaces.
      • Concern that these interfaces could be removed quickly (provisional only requires 6 months to deprecate/remove). Implementation might not be complete before the transition to the new governance rules for v5.
        • Rules would let this happen, but may not be likely to happen.
        • Provide some assurance that during the transition there won’t be a lot of depreciation/removal in the v4 -> v5 transition.
      • ASC membership should have an advocate to keep the interface and prevent depreciation. A group that can stand up and say they are working with the interface, and the ASC group should respect that effort and let the team work through the issue.
      • Would a minimal amount of time that an interface should be “provisional” before it can start the depreciation process?
        • Would like the flexibility to remove an item quickly if the author knows that there was a mistake in the interface.
    • Would it be helpful to reinforce:
      • The deprecation/removal timeline for provisional/stable, Provide example minimal timelines.
        • Concern about the pace of deprecation:
        • Suggestion is to have a forced timeline for release:
          • For example, once a change (add/remove/update) is made then a release will occur in X quarters.
          • Governance restricts to at most 1 major release a year. No wording on what forces a major release.
          • Maybe a clarification that deprecation is adequate justification for a major release. Does not tie the group to being required to release, but provides justification for a release.
            • Suggestion that we add a sentence identifying the triggering mechanism to start the pipeline for release. Once triggered then a fixed window for release is defined. Maybe with flexibility to delayed 1 quarter?
          • Don’t want to get into an indefinite delay of a release for “just one more thing… once it’s ready”
          • (Josh) Add this topic for discussion next week.
      • New interfaces/attributes can be introduced as replacements even while the old interfaces are being deprecated/removed.
      • Functional chapters will help focus attention on interfaces.
      • PMIx has a permissive interface structure
        • Most behavior can be adjusted via attributes.
        • Some may need a new interface
        • Any implementation is allows to choose the subset of the interfaces/attributes that they support. This means that an implementation is not forced to support an interface/attribute that is introduced in the standard. Implementers can decide if/when it is necessary to support their user base.
  • Please review the RFC below on scheduler interfaces:

Action Items

  • (Josh) Setup mailing list for each working group
  • (Josh) Work on LaTeX markers for "provisional"/"stable"

Home

Working Groups

Events

Helpful How To...

ASC Quarterly Meetings

ASC Monthly Meetings

Clone this wiki locally