Summary
Extend the hpc status <id> detail rendering (added in #5) to PJM clusters. Currently only Slurm has a detail_cmd / parse_detail override, so PJM jobs always fall back to the prior single-line Job <id>: <state> display.
Background
#5 added per-scheduler accounting display via Scheduler.detail_cmd / Scheduler.parse_detail, returning a JobDetail(state, exit_code, elapsed, max_rss, req_mem) dataclass. Slurm fetches it via sacct -P. PJM was deferred at the time.
Proposal
Implement PJM equivalents using whatever accounting source PJM exposes (typical candidates: pjstat -E, pjstat -X, the per-job log under ~/.pjm/). Map the available fields onto the existing JobDetail shape; leave unsupported fields as the empty string so the CLI's "field or -" rendering still works.
Out of scope
- Changes to the Slurm detail path or the polling path.
- Adding new fields to
JobDetail.
Summary
Extend the
hpc status <id>detail rendering (added in #5) to PJM clusters. Currently only Slurm has adetail_cmd/parse_detailoverride, so PJM jobs always fall back to the prior single-lineJob <id>: <state>display.Background
#5 added per-scheduler accounting display via
Scheduler.detail_cmd/Scheduler.parse_detail, returning aJobDetail(state, exit_code, elapsed, max_rss, req_mem)dataclass. Slurm fetches it viasacct -P. PJM was deferred at the time.Proposal
Implement PJM equivalents using whatever accounting source PJM exposes (typical candidates:
pjstat -E,pjstat -X, the per-job log under~/.pjm/). Map the available fields onto the existingJobDetailshape; leave unsupported fields as the empty string so the CLI's "field or-" rendering still works.Out of scope
JobDetail.