Added worker info logging #7
Conversation
| #LLVM_LOCAL begin | ||
| log.msg(f" host: {workerinfo['host']}") | ||
| log.msg(f" admin: {workerinfo['admin']}") | ||
| log.msg(f" access_uri: {workerinfo['access_uri']}") |
There was a problem hiding this comment.
If for any reason a key is missing, we would get an exception here. How about using get with default value "" or something like that?
There was a problem hiding this comment.
Please look at line 444 above where workerinfo is created. It is guaranteed to have these keys
workerinfo = {
'admin': conn.info.get('admin'),
'host': conn.info.get('host'),
'access_uri': conn.info.get('access_uri'),
'version': conn.info.get('version')
}
Also note yield self.master.data.updates.workerConnected(..., workerinfo=workerinfo) does not change workerinfo.
We can also use conn.info.get('admin') directly, but it seems more expensive.
There was a problem hiding this comment.
Fair enough. self.master.data.updates.workerConnected just writes to the database and should not change the workerinfo indeed. We can relay on that and crashing is Ok if the assumption gets broken.
slydiman
force-pushed
the
add-worker-info-log
branch
from
fa2fa8f to
ad11fce
Compare
| #LLVM_LOCAL begin | ||
| log.msg(f" host: {workerinfo['host']}") | ||
| log.msg(f" admin: {workerinfo['admin']}") | ||
| log.msg(f" access_uri: {workerinfo['access_uri']}") |
There was a problem hiding this comment.
Fair enough. self.master.data.updates.workerConnected just writes to the database and should not change the workerinfo indeed. We can relay on that and crashing is Ok if the assumption gets broken.
slydiman
force-pushed
the
add-worker-info-log
branch
from
ad11fce to
5a19da6
Compare
| log.msg(f" system: {self.worker_system}") | ||
| log.msg(f" worker_commands: {self.worker_commands}") | ||
| log.msg(f" basedir: {self.worker_basedir}") | ||
| log.msg(f" environ: {self.worker_environ}") |
There was a problem hiding this comment.
Forgot to mention. Since we print out multiple lines one by one, the printout could be interleaved by other log messages from different threads. Maybe prepare the whole thing first, and then print it once? Would be much easier to read and track in the log.
Subj