On Mon, 25 Apr 2016 11:06:39 +0200 Felsch Marco felschm@tqsc.de wrote:
Dear Linaro Team,
I have problems to tell the lava-slave to take the right network interface.
For LAVA V2, you can ignore /etc/lava-dispatcher/lava-dispatcher.conf
My lab has the following network structure:
company-network | | +------------eth0-------------+ | | | LAVA-SLAVE-1 | | | | eth1 eth2 | | 10.250.20.1 10.250.21.1 | +-----------------------------+ | | +------+ +--------+ | | DUT-Group1 DUT-Group2 10.250.20.0/24 10.250.21.0/24 10.250.20.2-254 10.250.21.2-254
My first reaction here would be that things get a lot simpler if you run a second lava-slave to run the second DUT group and put both slaves inside the same subnet as the devices for that slave.
The slave is designed to be dumb - it does what it is told and has no knowledge of configuration on that particular slave. The slave is lightweight (certainly compared to V1) but it must also stay dumb, without the need for local configuration beyond how to contact the master.
company dhcp server. After some research I found that the pipeline device always took it from the default gateway: def dispatcher_ip(): """ Retrieves the IP address of the interface associated with the current default gateway. """ gateways = netifaces.gateways() if 'default' not in gateways: raise InfrastructureError("Unable to find default gateway") iface = gateways['default'][netifaces.AF_INET][1] addr = netifaces.ifaddresses(iface) return addr[netifaces.AF_INET][0]['addr']
The slave get the image artifacts via the eth0 network interface thats right, but the dut's get them from the slave (eth1 or eth2). Is there a way to tell lava to use the other network interfaces?
Use a second slave, instead of doing firewall / routing tasks on the slave.
The only configuration that the pipeline V2 dispatcher will use is the configuration sent from the server and it seems unlikely that your LAN configuration needs to be part of the device dictionary.