Jim Garlick

> Ahhh ok. I remember with my prototype I left failed units running for later analysis. Perhaps we should have an option for that in the future for situations such...

Ah yeah, it does seem like there should be more criteria checked before ENODATA is returned in that function. > Perhaps we just have to modify the libsubprocess client side...

> On the client side, unexpected ENODATA and possibly some other scenarios shall be assumed to be "internal fatal error" and handled accordingly. I assume that would mean `on_state_change()` is...

Just FYI, in case you were unaware, there is a design by Tom and Steven for "openmp style" dependencies described in [RFC 26](https://flux-framework.readthedocs.io/projects/flux-rfc/en/latest/spec_26.html) that IIRC tackles the need to express...

Alright, but if you call that "jobspec", we're going to have an operator in flux core with a cute gopher mascot. It does the same thing as the flux operator...

Might be good to review [RFC 26](https://flux-framework.readthedocs.io/projects/flux-rfc/en/latest/spec_26.html) as part of designing this. That spec is a bit of a chimera - the openmp deps were defined earlier, but not implemented,...

To review the current situation, in `rc1` we have: ``` if test $RANK -eq 0; then if test -z "${FLUX_DISABLE_JOB_CLEANUP}"; then flux admin cleanup-push

Another job manager metric that would be easy to capture and could give us insight into impact of things like partial release is node level resource utilization, e.g. average fraction...

Fixed some stuff - add `shutdown` script to dist manifest (whoops) - dropped commits that remove `flux admin cleanup-push` - temporarily add backwards compat code for cleanup scripts (avoids breaking...

I dropped the actual changes to the shutdown process from this PR (including `shutdown --force`) leaving only the switch from `cleanup-push` to a shutdown script since that change alone is...