Al Chu

rebased & re-pushed, mergifyio seemed to get stuck on something

thinking about this, is this important to or worth fixing? This isn't the only scenario we have were modules are inter-dependent. Perhaps longer out we could have some automatic event...

it would be nice if dependent modules would know the automatically "reload" themselves. Like perhaps some event stream publishes unloaded modules and dependent ones know to restart themselves or something....

from discussion in #4173, proper implementation will probably be > I would think you could add a new is_active function pointer to struct flux_watcher_ops, then implement a callback for each...

> However, besides the issues with using flux that you mention, I think whatsup(1) and cerebro's simplicity are their main advantage. Flux might be part of the problem that whatsup(1)...

> The heartbeat is sent by rank 0 to the other ranks over the tree, and it's for synchronization not monitoring. It's not like cerebro where each rank sends out...

> I'd actually suggest flux whatsup in this case if there isn't a strong reason to put it under the flux overlay command We used to have the `flux up`...

Seems like a good idea, instead of the user converting numeral to string.

Granted `flux job` is a plumbing tool, but I just have trouble seeing the use case where someone needs the number of a job state returned from `job-info.list`, so I...

i'm wondering if this issue should be resurrected given discussion in #4273, #4313, and #4234 - we may want to dump large amounts of job data into the archive in...