Aug092016 - openpmix/openpmix GitHub Wiki

##PMIx Developers Meeting

Date

Aug 9, 2016

Attendees:

Ralph, David, Josh, Artem, Boris, Chris

Minutes:

  • MCA infrastructure commit

    • Discussed desire to get this infrastructure into the repo so we can begin staging in framework abstractions. The commit doesn't impact behavior as the new code isn't called by anything - it will just compile.
    • Decision: go ahead and commit it

  • Extend PMIx_Tool support (PR #122, RFC #10)

    • Reviewed the list of changes and discussed possible impacts. Main impact to host resource managers is the need to be careful with assignment of data types when exchanging info to/from the PMIx server as some new data types were introduced so the tool could correctly understand what was being passed. Otherwise, the changes are transparent to current implementations
    • Decision: Ralph will update the PR, others are asked to review/approve as soon as possible so that other work can progress.

  • Revision of PMIx_Get behavior (PR #114, RFC #9)

    • Discussed how to store non-rank-specific data - e.g., data that relates to a specific node.
    • Decision: we will create a separate storage area for node-related data. Ralph will update the PR with the changes, others are asked to review/approve as soon as possible so that othe work can progress.

  • Support for "Put" updates

    • Discussed versioning of data versus simple invalidation. We don't have a real use-case for this right now. Currently, we append newly "put" data to the end of the existing data blob, and so the value gets overwritten at the client when they unpack the complete data blob. This means that memory footprint grows with repeated "put" of the same key, and so all we are talking about here is optimizing by removing this memory growth behavior.
    • Decision: set this aside for now and close the issue pending a real use-case.

  • Status of PMIx v2.0.0 release

    • Code freeze is delayed - hoping for early Sept
    • Mellanox requests a separate release with dstor be done earlier, without waiting for cross-version and other features to be completed.
    • Decision: we will branch v2.0.0 now and restrict all patches to dstor bug fixes. Once dstor is ready, we will release v2.0.0. We will then release the rest of the feature updates - this likely will have to be a 3.0 series due to the API changes.

Home -> 4 Meetings -> 4.1 developers

⚠️ **GitHub.com Fallback** ⚠️