(This is databox 0.5.2 on amd64 debian VM)
There seems to be a race condition when a driver is restarted to update the core-network configuration for the new container (new IP address). As a result whitelisted DNS lookups that are attempted early the driver's execution can fail.
E.g. I see this if i configure the twitter driver then restart it - the initial DNS lookup fails for api.twitter.com even though it is whitelisted. From the core-network logs the DNS lookup is received and refused before the previous whitelist info is migrated from the old IP to the new IP.
Obviously a workaround might just be to sleep initially on start-up, and/or retry potentially early network operations.
But it would be nicer to have some way for the driver to know that it should be safe to proceed.
(The effect I see is the same as the initial error in #282 but I don't see it as a result of the login action, but when the container is restarted)
(This is databox 0.5.2 on amd64 debian VM) There seems to be a race condition when a driver is restarted to update the core-network configuration for the new container (new IP address). As a result whitelisted DNS lookups that are attempted early the driver's execution can fail. E.g. I see this if i configure the twitter driver then restart it - the initial DNS lookup fails for api.twitter.com even though it is whitelisted. From the core-network logs the DNS lookup is received and refused before the previous whitelist info is migrated from the old IP to the new IP. Obviously a workaround might just be to sleep initially on start-up, and/or retry potentially early network operations. But it would be nicer to have some way for the driver to know that it should be safe to proceed.
(The effect I see is the same as the initial error in #282 but I don't see it as a result of the login action, but when the container is restarted)