linaro-validation April 2016

linaro-validation@lists.linaro.org

4 participants
3 discussions

by Felsch Marco

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.

8 years, 8 months

Re: [Linaro-validation] [Lava-announce] 2016.4 production release

by Milosz Wasilewski

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

8 years, 8 months

Re: [Linaro-validation] linaro-validation Digest, Vol 50, Issue 6

by Felsch Marco

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. >

8 years, 9 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation April 2016