Replace the "log" server module fn with a "log2"

[rhc54]

The current "log" server module function was defined with a void return. This contrasts with most of the other module functions which characteristically return a pmix_status_t, thereby supporting a return status that indicates if the function is not supported or has been atomically completed.

Add a replacement "log2" function that is identical in signature except for returning a pmix_status_t instead of void. Deprecate the current "log" function.

[rhc54]

Please use emoji reactions ON THIS COMMENT to indicate your position on this proposal.

• You do not need to vote on every proposal
• If you have no opinion, don't vote - that is also useful data
• If you've already commented on this issue, please still vote so
  we know your current thoughts
• Not all proposals solve exactly the same problem, so we may end
  up accepting proposals that appear to have some overlap
  This is not a binding majority-rule vote, but it will be a very
  significant input into the corresponding ASC decision.

Here are the meanings for the emojis:

• Hooray or Rocket: I support this so strongly that I
  want to be an advocate for it
• Heart: I think this is an ideal solution
• Thumbs up: I'd be happy with this solution
• Confused: I'd rather we not do this, but I can tolerate it
• Thumbs down: I'd be actively unhappy, and may even consider
  other technologies instead
  If you want to explain in more detail, feel free to add another
  comment, but please also vote on this comment.

[rhc54]

@neicker Does this look okay to you?

[neicker]

@neicker Does this look okay to you?

Looks good to me.

[neicker]

While looking at this I remembered that I had more issues with pmix_server_log_fn_t (and PMIx_Log, etc.):

• PMIx_Log[_nb]() and the section on "Log attributes" (i.e. sections 13.4.1-13.4.3) report way more attributes than mentioned in the section on pmix_server_log_fn_t (and now pmix_server_log2_fn_t). I tend to remember that at least some of them are passed to the server function.
• I found no place in the standard that defines which attributes are expected to be passed in data and which in directives. I derived from the OpenPMIx sources the expected place for some of them, but I guess it would be good to mention this in the standard.
• For the PMIX_LOG_EMAIL attribute one might deduce from its type (pmix_data_array_t) that other PMIX_LOG_EMAIL_* attributes are expected to be passed in this list. But this seems not to be stated anywhere in the standard explicitly.

Unclear to me if we want to handle this in this PR or if I should rather open a new issue?

[rhc54]

I'll try to address those points here - thx!

[rhc54]

@neicker I have updated the text to address your questions - please see if this is adequate or further clarification is required.

[rhc54]

@naughtont3 Conflicts resolved - should be good to go!

[naughtont3]

Note from 25Q3 meeting, will allow more time for reviews/comments and bring for vote at next quarterly (25Q4).

[abouteiller]

A number of these have been removed from this list but not reintroduced in another list, should they be added to the list of optional attributes above?

[rhc54]

PMIX_LOG_EMAIL is still in the list, just moved to the section immediately above this one. The other LOG_EMAIL_xxx attributes are listed in the PMIX_LOG_EMAIL description as they are to be included in the pmix_data_array_t for that attribute. We can split them into a list within that description (as was done for the stats area) if that helps.

[naughtont3]

2025-Q4 Vote passed: 7 yes, 0 No, 0 Abstain

[rhc54]

@naughtont3 Can you please click off the review button?

[rhc54]

Rebased without conflicts!