You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Cluster API traps stdout/stderr of controller and engines because it's meant to be used interactively. But that's where information about why connection failures occurred is going to be, and it's frustrating to need to start a whole new cluster with log_level=logging.DEBUG to get a run with output you can see.
It would be good to be able to get this info after a process died that you didn't expect to. The answer to this is probably to pipe process output to a file and keep track of that file and provide an API to retrieve it.
The text was updated successfully, but these errors were encountered:
The SSH launchers are piping to a file and have a get_output() method. This seems to be working well, and we can promote it to the base lanucher and e.g. show output on failure.
Thing I just learned that I thought would be trickier:
works and the subprocess continues to produce output to the file even after the parent exits. That means we can have a very simple implementation of getting output that writes to a file and just read that file when an engine dies.
The Cluster API traps stdout/stderr of controller and engines because it's meant to be used interactively. But that's where information about why connection failures occurred is going to be, and it's frustrating to need to start a whole new cluster with
log_level=logging.DEBUG
to get a run with output you can see.It would be good to be able to get this info after a process died that you didn't expect to. The answer to this is probably to pipe process output to a file and keep track of that file and provide an API to retrieve it.
The text was updated successfully, but these errors were encountered: