Dear Linaro Team,
I have problems to tell the lava-slave to take the right network interface.
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
If I use the {SERVER_IP} macro lava took all the time the lava-slave-1
network interface where the default
gateway is defined. The slave is getting the default gateway via the
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?
I have changed the /etc/lava-dispatcher/lava-dispatcher.conf file to
tell lava to use the eth1 and eth2
interface:
LAVA_NETWORK_IFACE = eth1
eth2
I use the new pipeline design for the lava-lab.
Thanks a lot.
On 20 April 2016 at 11:51, Neil Williams <neil.williams(a)linaro.org> wrote:
> lava-server changes:
> Add support for python-django-debug-toolbar
> Deleting V1 filters now cascade delete image chart filters.
> Reduce the number of SQL queries used on common pages.
> Improve scheduler iterative performance.
> Add support for deleting unused tokens
> Stop runaway healthchecks in V2.
> Migrate option_list to argparse for django 1.8 and later.
> Allow authentication with result export in V2
> Drop references to Ubuntu beyond 2016.9.post1
> Implement omitting individual results from queries in V2
> Indicate omitted results and allow including them back in.
> Add a management command for refreshing queries
> Change V1 measurement field to be float only.
> Clean up top-level documentation
> Introduce limit to queries in V2.
> * Suggest python-django-debug-toolbar
> * Refresh all V2 queries during package postinst to ensure
> materialized views are available.
>
> lava-dispatcher changes:
>
> Allow for adb not being available on some arches
> Support ramdisks that are not compressed
> Move the ramdisk header requirements into the device template
> Fix calling the Bzr unit tests
> Use tar flags from deployment data when unpacking overlay
> kvm-aarch32: introduce device type for 32-bit guest on 64-bit KVM
> host
> kvm-aarch64: expose a virtual random number generator (RNG) to the
> guest
> Provide an apache2 config for V2 workers
> Initial support for device using GRUB bootloader in V2
> Add in the ability to halt the V1 master image before powering off
> No longer require ssh options or identity_file
> Don't use -p port in SCP options
>
> https://validation.linaro.org/ will be updated in due course (probably
> at the start of next week).
It's release week next week (commencing on April 25th). Could you
please postpone to first week of May?
milosz
>
> Packages have been uploaded to Debian (unstable) and will appear on
> the mirrors in due course. Once these versions migrate into stretch,
> backports can be made to jessie-backports.
>
> https://tracker.debian.org/pkg/lava-server
>
> https://tracker.debian.org/pkg/lava-dispatcher
>
> https://qa.debian.org/developer.php?email=pkg-linaro-lava-devel%40lists.ali…
>
> The production repo also has this release.
> https://validation.linaro.org/static/docs/v2/installing_on_debian.html#lava…
> https://validation.linaro.org/static/docs/v1/installing_on_debian.html#lava…
>
> Information will also appear at
> http://releases.linaro.org/components/lava/ in due course.
>
> --
>
> Neil Williams
> =============
> neil.williams(a)linaro.org
> http://www.linux.codehelp.co.uk/
> _______________________________________________
> Lava-announce mailing list
> Lava-announce(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lava-announce
Dear Linaro Team,
no I am not confusing with the ssh operations used for the hacking session.
My problem is to access our company git server. It just supports ssh access.
On 25.03.2016 13:00, linaro-validation-request(a)lists.linaro.org wrote:
> Send linaro-validation mailing list submissions to
> linaro-validation(a)lists.linaro.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linaro.org/mailman/listinfo/linaro-validation
> or, via email, send a message with subject or body 'help' to
> linaro-validation-request(a)lists.linaro.org
>
> You can reach the person managing the list at
> linaro-validation-owner(a)lists.linaro.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of linaro-validation digest..."
>
>
> Today's Topics:
>
> 1. git ssh access (Felsch Marco)
> 2. Re: git ssh access (Neil Williams)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 24 Mar 2016 15:36:52 +0100
> From: Felsch Marco <felschm(a)tqsc.de>
> To: linaro-validation(a)lists.linaro.org
> Subject: [Linaro-validation] git ssh access
> Message-ID: <56F3FB84.5020609(a)tqsc.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Dear Linaro Team,
>
> does LAVA support ssh access for git to receive test definitions?
>
> e.g.
> definitions:
> -repository:ssh://git.linaro.org/lava-team/hacking-session.git
> from:git
> path:hacking-session-debian.yaml
> name:hacking
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 24 Mar 2016 15:33:51 +0000
> From: Neil Williams <codehelp(a)debian.org>
> To: linaro-validation(a)lists.linaro.org
> Subject: Re: [Linaro-validation] git ssh access
> Message-ID: <20160324153351.25e552ab(a)sylvester.codehelp>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, 24 Mar 2016 15:36:52 +0100
> Felsch Marco <felschm(a)tqsc.de> wrote:
>
>> Dear Linaro Team,
>>
>> does LAVA support ssh access for git to receive test definitions?
>>
>> e.g.
>> definitions:
>> -repository:ssh://git.linaro.org/lava-team/hacking-session.git
>> from:git
>> path:hacking-session-debian.yaml
>> name:hacking
> No, it does not and I'm not sure how that could be expected to work -
> ssh needs a user & authorisation. Which ssh user is this expected to be
> doing the clone? How does this get configured at the remote repository?
>
> Cloning a git repo using ssh is typically for read:write
> operations to allow git push and similar. That is not something
> LAVA is likely to be doing. There are also security implications of
> allowing a LAVA test shell to have SSH credentials with third party
> sites.
>
> What are you trying to achieve? With the example given, git.linaro.org
> offers http and https. Are you confusing this with the ssh operations
> used for the hacking session itself? That is your user and your private
> key authorising against your public key which needs to be included in
> the job submission.
>
> If what you want is some level of encryption to guard against packet
> sniffing, https is what you want.
>
