Hi all,
I'm writing scripts in Python using the LAVA XML-RPC API to parse data
from my bundle stream.
I read the documentation for the dashboard.get_filter_results()
method. I understand that by default, the count parameter is set to 10
as shown here:
get_filter_results(filter_name, count=10, offset=0)
However, if I change the value of count from 10 to 100, I run into this error:
bbb_results = server.dashboard.get_filter_results(bbb_filter_name, count=100)
TypeError: __call__() got an unexpected keyword argument 'count'
and bbb_filter_name is set to "~lisatn/pmwg-bbb"
I would like to be able to display more than 10 results (currently
have 75 pm-qa test runs for beaglebone-black), or am I
misunderstanding the purpose of count?
Lisa
# Progress
* LAVA-1309: Support for manual start of virtual machines in vm group jobs
* LAVA-1297: Allow Multiple lava-test-shell test executions on a single target
* Fix for regression against busybox-provided wget (deployed to production)
Time:
* 20% LAVA-1309
* 40% LAVA-1297
* 40% bug fixing
# Plans
* Fix for bundle submission when using `no_autostart_vms`
* Prototype new design for lava-dispatcher
--
Antonio Terceiro
Software Engineer - Linaro
http://www.linaro.org
And of course when I reply from my phone I forget the list.
---------- Forwarded message ----------
From: "Michael Hudson-Doyle" <michael.hudson(a)canonical.com>
Date: 27 May 2014 22:12
Subject: Re: [Linaro-validation] using debian-installer and preseeds to
deploy in lava
To: "Neil Williams" <codehelp(a)debian.org>
Cc:
On 27 May 2014 20:37, "Neil Williams" <codehelp(a)debian.org> wrote:
>
> On Tue, 27 May 2014 15:00:07 +1200
> Michael Hudson-Doyle <michael.hudson(a)linaro.org> wrote:
>
> > For reasons that probably aren't especially good[1] I've been poking a
> > bit today at using a preseeded debian-installer to get an image onto a
> > LAVA system. It turns out to be mostly possible, with a job like
> > this:
> >
> > http://paste.ubuntu.com/7526204/
> >
> > and a preseed like this:
> >
> > http://paste.ubuntu.com/7526152/
> >
> > but there is a hard coded timeout on boot_linaro_image of 5 minutes,
> > which is not long enough for d-i to run. Oh well!
>
> :-(
>
> How far did the install get? Is it just a case of saving a few seconds
> on downloads or doubling the timeout?
More the latter, I think. I haven't timed it, but I think it takes about 15
mins.
> Maybe skip the openssh-server tasksel and install that as a separate
> action after the install has booted?
Yes, that's a good idea. I'll try tomorrow.
> ports.ubuntu.com is often *really* slow - a local mirror of that will be
> a lot more useful, both for the archive and the installer image.
I don't think that's a huge part of the issue here – when I (unpreseededly)
d-i-ed some mustangs last week, the first wasn't much slower than the rest
(which presumably got most things from squid).
> > So I guess I have two questions really:
> >
> > 1) Would it be possible to override this timeout? I.e. add a
> > timeout= parameter to boot_linaro_image?
>
> There's no support for that right now - it may be better to have a
> install_image action added to the list of elements for the upcoming
> sprint.
>
> > 2) Is there any sense in LAVA supporting d-i as a deployment
> > method? I guess the dispatcher could even handle generating the
> > preseed for you, at least mostly.
>
> Yes, the dispatcher certainly could handle the pre-seeding of debconf
> for d-i and for other package installs, using parameters where
> required. It would be a different kind of deployment with custom
> deployment data based on the underlying OS.
>
> A separate action would be the best way to implement that.
Oh yes, a separate action is definitely the Right Thing™.
Cheers,
mwh
(Phone reply, apologies for typos)
> --
>
>
> Neil Williams
> =============
> http://www.linux.codehelp.co.uk/
>
>
> _______________________________________________
> linaro-validation mailing list
> linaro-validation(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-validation
>
Hello all,
For reasons that probably aren't especially good[1] I've been poking a
bit today at using a preseeded debian-installer to get an image onto a
LAVA system. It turns out to be mostly possible, with a job like this:
http://paste.ubuntu.com/7526204/
and a preseed like this:
http://paste.ubuntu.com/7526152/
but there is a hard coded timeout on boot_linaro_image of 5 minutes,
which is not long enough for d-i to run. Oh well!
So I guess I have two questions really:
1) Would it be possible to override this timeout? I.e. add a timeout=
parameter to boot_linaro_image?
2) Is there any sense in LAVA supporting d-i as a deployment method? I
guess the dispatcher could even handle generating the preseed for
you, at least mostly.
Cheers,
mwh
[1] AFAICT there is no way to install an image onto the disk of a LAVA
mustang and then boot that. There is surely a more direct fix for
this immediate problem...
# Progress #
* LAVA-1192 Archive LAVA log files older than a time limit
* LAVA-1320 Archive root directory
* LAVA-1321 Adjust UI to show job file is archived
* LAVA-1289 Extend accounting for test script versions
* LAVA-1290 Remove Test Definition in Table in Dashboard
* LAVA-1291 Record the version of the repository
* LAVA-1292 Add an LTS helper function for adding test attributes
* LAVA-1322 Allow additional properties for testdef_metadata in bundle
format
* LAVA-1265 Set the order of items within listings in the admin interface
* LAVA-1324 Fix all pages within dashboad app
* LAVA-1325 Fix all pages within lava scheduler app
* LAVA-1326 Overall admin pages and lava server testing
* various code reviews
* Time
* Cards - 80%
* various code reviews - 20%
# Plan #
* pending LAVA cards
* bug fixes
--
Senthil Kumaran
http://www.stylesen.org/http://www.sasenthilkumaran.com/
# Progress #
* LAVA-333
* Completed the migration of playground to packaging with documentation
* Ported Health History Log changes to packaging
* Added conditional in packaging branch to support Launchpad OpenID by default and Google+ as an option to allow easy migration of Launchpad groups.
* Time
* packaging : 30%
* migration: 70$
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
2014.04.23.14.01-1 is now available for jessie and sid,
2014.04.23.14.08-1ubuntu1 for trusty and unicorn.
This update addresses the OpenID support. Launchpad had an issue
previously because the CACert certificates were removed from the
ca-certificates package. Launchpad has since migrated to a certificate
which is supported by current (and old) ca-certificates packages.
The packaging branch migrated to Google+ OpenID during development but
that would not be an easy migration for the group support in LAVA.
Support for OAuth2 is being investigated.
This update re-instates Launchpad as the default OpenID server for the
packaging branch and includes documentation for how to stay with
Google+.
http://playground.validation.linaro.org/static/docs/installation.html#using…
"OPENID_SSO_SERVER_URL": "https://www.google.com/accounts/o8/id",
This change will be respected by future lava-server upgrades, so the
choice of OpenID service is open to the local admin.
(If there are other OpenID servers people want to use, this support
should work but note that OAuth2 is the preferred option, so it may
only be a temporary step.)
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
