On Thu, 10 Oct 2013 17:27:03 +0100 Dean Arnold Dean.Arnold@arm.com wrote:
Hi Neil,
Earlier today I configured two new virtual machines to test the master/worker setup and I have managed to get this to work now. For this I installed a the master and slave from scratch with the LAVA_DB_ALLOWREMOTE variable set on the master, and all went well. I was able to do a couple of qemu runs on the worker with no issues.
OK.
It looks as though the problem I was seeing on our production LAVA setup, was down to my master configuration, which wasn't correct. When doing an upgrade of a master instance, the deployment tool doesn't carry out the steps for enabling remote workers, even with the LAVA_DB_ALLOWREMOTE variable set. I had then corrected some of the steps manually, but had missed a couple of bits, which is why I ended up with a *kind of* working setup.
Please file this as a bug against lava-deployment-tool. There are other parts of the tool which fail to run on upgrade and it's time that this is fixed properly instead of adding another workaround.
TBH the environment variable should be replaced by a wizard question and a config option.
I don't know if this is something you guys would like to be automated by the lava-deployment-tool during upgrades, or whether some steps on the wiki for the extra bit of config would be enough? If you need me to raise a ticket/bug for this I can do?
The errors which occur when it goes wrong are so obscure and misleading that this needs to be handled inside the tool properly, especially as it fails on upgrade.
Please file a bug against lava-deployment-tool to get the remote worker support working without an environment variable during upgrades and add any comments you have regarding why your master postgresql configuration still wasn't right.
It needs to be possible to take a "stand-alone" master with it's own devices and add a remote worker using lava-deployment-tool upgrade just using the tool and without breakage.