| Re: [ptp-dev] PTP RM commands and proxy events |
In reading thru some documentation yesterday, it looks like a couple other things to consider are commands/events to checkpoint an application and maybe restart that application. Also, possibly commands and events to query availability of hardware on a node or in a pool, such as special network adapters, and maybe maybe queries for the properties of a resource pool or job class such as resource limits, priorities, etc. That might be helpful to users in deciding what job class, resource pool, etc to use for a job.
> Some comments below. Craig/Randy, please correct me if I've got
> anything wrong.
>
> Greg
> > For resource manager commands, additional commands that might be
> > useful
> > include commands to query node availability, query resource pools,
> > query
> > job classes, query job queues, query what's running on the machine,
> > what's
> > running on nodes, change job priority, cancel pending jobs (vs
> > killing a
> > running job), disconnect from and reconnect to proxy. If the proxy is
> > expected to inform the resource manager of the complete state of the
> > machine, queues, etc, at startup, some of these queries might not be
> > required.
>
> We originally had commands for all these things (at least the query
> commands anyway), but they were never needed with the event model. We
> eventually removed them, but they could be added again if there was a
> pressing need.
>
> >
> > There's probably some additional commands required to initiate an
> > application under debugger control since the proxy may need to do
> > extra
> > work in that case.
>
> Yes. At the moment all that is passed is a flag indicating that the
> debugger is to be started, and some debugger options, such as the
> location of the executable, etc. If you can think of other
> information/commands that might be needed, please let us know.
I think the flag and debugger options are sufficient. Parallel Environment has a way to load the application with it suspended before entry to main, so debuggers can then attach to the application. The debugger somehow has to be passed node/pid pairs so that it knows where to start debugger sessions and what to attach to.
Dave