Job Control and Monitoring APIs

[rhc54]

Signed-off-by: Ralph Castain rhc@open-mpi.org

[jjhursey]

The RFC seems to just the template. I think you might have forgotten to push.

[adammoody]

Thanks @rhc54. This looks good to me. The heartbeat keys you have defined provide more capability even than my initial proposal.

Can we define default settings in the standard in case a user doesn't specify all keys? For example, can we default the "missed beats" to be 1, unless the user sets it to something else?

[rhc54]

Sure - I'll add that to the RFC. Please pass along any other suggestions!

[rhc54]

@bosilca @abouteiller Please see what you think, especially with respect to the monitoring capability.

[rhc54]

@adammoody Can you please review and approve/comment?

[abouteiller]

This example makes me think about the SIGNAL/EVENT.

In this example, the requestor sets that a given signal should be triggered at the target clients. However, if the requestor is a tool, and the client an application process, the tool may manage a variety of application client types that employ a checkpointing system of their liking. It seems to me that in such cases, the target client should publish to its local server what is the signal/event that should be used to trigger a checkpoint, which would leave the requestor free of knowing what particular signal that client needs to trigger.

[abouteiller]

The monitoring part looks fine.

[rhc54]

I like that idea - will update to include it. Thanks!

[rhc54]

Shall be committed upon addition of example code

[adammoody]

@rhc54 Thanks for your time and effort to add the monitoring support. This will be a really useful feature for people.

As a next step, I'll work with you to write up some examples that could be used in cut-and-paste form for app developers, e.g., show the client code to register a heartbeat and then email the user and have the job killed if it gets stuck. The heartbeat macro you show is a great start along these lines.