The logs in Brent's comment above seem to indicate that there was an 8 minute delay in the worker_config script before it failed:
2020-06-20T01:10:23.000 worker-1 /etc/init.d/worker_config: warning DNS query failed for worker-1
2020-06-20T01:18:48.000 worker-1 /etc/init.d/worker_config: warning DNS query failed after max retries for worker-1 (620 secs)
This could indicate that the "dig" command hung, which seems to be a common issue. If that was the case, we could improve robustness by wrapping the "dig" command with "timeout" command to ensure this didn't happen.
Setting the LP to incomplete and assigning to the originator to see if the logs might still be available. If we don't have the logs, we'll have to close this one until it can be reproduced and logs collected.
The logs in Brent's comment above seem to indicate that there was an 8 minute delay in the worker_config script before it failed: 20T01:10: 23.000 worker-1 /etc/init. d/worker_ config: warning DNS query failed for worker-1 20T01:18: 48.000 worker-1 /etc/init. d/worker_ config: warning DNS query failed after max retries for worker-1 (620 secs)
2020-06-
2020-06-
This could indicate that the "dig" command hung, which seems to be a common issue. If that was the case, we could improve robustness by wrapping the "dig" command with "timeout" command to ensure this didn't happen.
However, the log files at https:/ /files. starlingx. kube.cengn. ca/launchpad/ 1884335 are no longer available, so I can't confirm whether there were other logs in between the above two logs.
Setting the LP to incomplete and assigning to the originator to see if the logs might still be available. If we don't have the logs, we'll have to close this one until it can be reproduced and logs collected.