linaro-validation

linaro-validation@lists.linaro.org

818 discussions

by Dave Pigott

------------ origen02 ------------ http://validation.linaro.org/lava-server/scheduler/job/35250 When trying to boot the test image, it went into a panic. I went onto the board and booted it both into master and test images and it was fine. So it looks like it was a random glitch. Back online to re-test. ------------ origen09 ------------ http://validation.linaro.org/lava-server/scheduler/job/35134 Dropped into initramfs on test image boot. Booted up test image, and it sat for ages doing recovery on mmcblk0p6, which is testrootfs. Let it complete fsck, then did a reboot. Still recording errors, so replaced sd card with new image. Looks like one of the rare sd card failures. A health check finding a real problem. :) ------------ panda04 ------------ http://validation.linaro.org/lava-server/scheduler/job/35095 Android glitch of some sort - home screen problem. Put back online to retest. -------------------- snowball06/08 -------------------- http://192.168.1.10/lava-server/scheduler/job/35179 eth0 failed to come up. We see this a lot with snowballs. Perhaps there's a known bug in the master image we use (12.02)? Thanks Dave

13 years, 1 month

lava-cloud04 and lava-cloud05 issues

by Andy Doan

Hey Dave, I was messing around with our VM's today and noticed a couple of issues: 1) lava-server05 bridge not working When I launched an instance that started on lava-cloud05 I couldn't get to it via its public IP address. lava-cloud05 could ping the public IP, but not lava-cloud01 or anything else in our lab. 2) lava-server04 has errors when trying to launch an instance I have no idea what was going on here. Luckily I was able to do what I wanted which was to get two instances going. fastmodels02 found its way to lava-cloud02 which was idle.

13 years, 1 month

New Origen boards

by Dave Pigott

Hi al, I have three of the new Samsung Origen Pegasus boards. What's the priority in getting them deployed in LAVA? I have all the support hardware necessary, so can do it pretty much anytime. It's a day sized chunk of work. Thanks Dave

13 years, 1 month

LCE12: QA Pilot test plan kick off at Connect 2012

by Naresh Kamboju

Hi All, Greeting from QA Team. INFO: The QA Services team can offer test planning and sign-off services to Working Groups for their major road-map items. We are planning to kick off road-map piloting for Linaro Engineering efforts at Connect 2012. Card http://cards.linaro.org/browse/CARD-140 briefs about QA's road-map sign off piloting. STATUS: We have been providing QA services to projects like big.LITTLE System, big.LITTLE MP and general Android and Ubuntu Daily, Weekly and Monthly release testing. We have well defined test plans, test execution cycles and test plan sign-off for above Projects. ACTION: We would like to have a pre-discussion about your (Working Group) requirement and expectation from QA team regarding creating test suite, planning, development, integration with Ubuntu, Android and LAVA. Please also let us know the cards/projects which are in a need of QA services. we are ready to help you. MEET: we would also like you to invite for QA meeting planned at LCE12 for further discussion http://summit.linaro.org/lce12/meeting/21226/roadmap-card-qa-and-sign-off/ Regards, QA Services Linaro Platform http://wiki.linaro.org/Platform/QA

13 years, 1 month

staging/dogfood update

by Andy Doan

Hey Guys, I've just got through a big round of lava-dispatcher testing over the past 2 days. I started mostly getting things working locally, and then I transfered to getting things working on dogfood this afternoon. = dogfood dogfood is not set up in a similar way as staging in. I copied the restore-staging-db script from lava-deployment-tool and adapted it restore-dogfood-db locally. The big difference is that it marks its configured boards as OFFLINE. Right now the best way to use dogfood is to mark a board offline in staging (including a note why is nice), and then marking it online in dogfood. = staging our bugs in staging *should* be fixed now. I have health checks running on everything, but its currently at the same dispatcher level as dogfood, so I don't expect changes. I'm going to be on vacation tomorrow and out of town over the weekend. However, I plan to trry and keep submitting different types of jobs to staging over the weekend to validate its still working well. This should lead to the big moment on Monday when we'll publish to the 2012.10 release. -andy

13 years, 1 month

Re: [Linaro-validation] test / test case management in LAVA

by Zygmunt Krynicki

W dniu 18.10.2012 16:28, Abner Silva pisze: > Hello, > So on a tangent somewhat, I've started a document (feel free to contribute) on https://docs.google.com/document/d/1WxWJ5kQj3zVKB45fOOEpk2udrRM1Z0RgHly_3KQ… Please add comments there. This will allow us to have a better understanding of the topic before UDS/Linaro Connect even starts Thanks ZK -- Zygmunt Krynicki s/Linaro Validation Team/Canonical Certification Team/ s/Validation/Android/

13 years, 1 month

Re: [Linaro-validation] test / test case management in LAVA

by Michael Hudson-Doyle

Abner Silva <abner(a)collabora.co.uk> writes: > Hello, > > Sorry for my delay. I have been busy with other things. > > On Wed, 2012-10-17 at 13:47 +1300, Michael Hudson-Doyle wrote: >> We're going to be talking about test case management in LAVA at the >> Connect. I've brain-dumped some of my thoughts here: >> >> https://wiki.linaro.org/Platform/LAVA/Specs/TestCaseManagement >> >> Comments welcome. But if all you do is read it before coming to the >> session, that's enough for me :-) > > It's good to see people discussing it. I'm glad. > > Here are some comments about this initial spec: > > > [Terminologies] > > As a section says, it's not going to change the > test/testcase/testrun/testresult terminology for now. It would be good > to have each of these terminologies well explained somewhere. It might > be crystal clear to you guys, but for other people it might be confusing > when attending to the Linaro Connect session, since these same > terminologies are commonly used to represent other QA artifacts. I've added something to the wiki page now: https://wiki.linaro.org/Platform/LAVA/Specs/TestCaseManagement#Assumptions Does that help? > [Test case concept] > > The first thing that passed through my head when I started thinking > about TC (sorry, I don't know what to call it considering LAVA naming) > inside LAVA, was that it would be a different Object/artifact/file, and > not really represented by the test definition concept/file LAVA already > have nowadays. > > Is that what you guys are planning to do? To consider the test def that > we have today as the TC entity? If yes, I probably have some questions > about it. The way I was thinking about it was to extend the test and test case models to be much richer (currently they're mostly just a normalization for the names of testruns and testresults). Cheers, mwh

13 years, 1 month

Re: [Linaro-validation] test / test case management in LAVA

by Zygmunt Krynicki

W dniu 18.10.2012 16:28, Abner Silva pisze: > Hello, > > Sorry for my delay. I have been busy with other things. Hey Abner, good to see you here again! > It's good to see people discussing it. I'm glad. > > Here are some comments about this initial spec: > > > [Terminologies] > > As a section says, it's not going to change the > test/testcase/testrun/testresult terminology for now. It would be good > to have each of these terminologies well explained somewhere. It might > be crystal clear to you guys, but for other people it might be confusing > when attending to the Linaro Connect session, since these same > terminologies are commonly used to represent other QA artifacts. They are somewhat explained in the glossary section of linaro-dashboard-bundle python library: http://linaro-dashboard-bundle.readthedocs.org/en/latest/glossary.html I'd gladly accept patches to that library to reword / improve it [edit: I cannot accept patches there anymore but I'm sure we can correct that] > [Test case concept] > > The first thing that passed through my head when I started thinking > about TC (sorry, I don't know what to call it considering LAVA naming) > inside LAVA, was that it would be a different Object/artifact/file, and > not really represented by the test definition concept/file LAVA already > have nowadays. > > Is that what you guys are planning to do? To consider the test def that > we have today as the TC entity? If yes, I probably have some questions > about it. I think that a test definition (currently) merely specifies test (suite) and it can have many test cases as an effect of running. Having said that I'd like to see a test definition that clearly states all of the test cases it can produce, with sensible description/meta data for each of them. I guess it depends on the number of test cases, behemoths such as LTP with test cases in the thousands are probably going to not offer per-test case meta-data just yet. Still, whatever we choose to do, initially I would recommend a discovery phase where we enumerate all the things that we have encountered and classified. As we gather visibility on that data we can improve the definitions of our terminology. In the longer term I would like to see common vocabulary that spans "development camps" so that when LAVA developers talk to Checkbox developers and Phoronix developers (for example) there are no misunderstandings. Thanks ZK -- Zygmunt Krynicki s/Linaro Validation Team/Canonical Certification Team/ s/Validation/Android/

13 years, 1 month

Fastmodels v8

by Dave Pigott

Hi guys, I've deployed a new compute node in the cloud, and upped the VCPU allocation in the project, but I'm seeing some oddities. The "nova-manage service list" command tells me that nova-network and nova-compute are not running on 02 (I knew that and am working on restoring it) and 03 and 05. However, the instances that are running on those nodes are still accessible. Additionally, when I try to create an instance, it immediately errors. I've had similar problems in the past, and typically I had to reboot all nodes, starting with the control node (lava-cloud01). I also believe (note wording) I need to do an update/upgrade on every node to bring the cloud up to latest revisions of nova/services. Obviously, if I do this, it will disrupt staging, dogfood and fastmodels, so this is a warning that absent from any dissent, I will reboot the cloud tomorrow morning. If you would rather defer this let's discuss when it should be deferred to. Obviously, to get the v8 fast model instance up is paramount. Thanks Dave

13 years, 1 month

How can I deploy lava-scheduler-tool in buildout lava instance

by YongQin Liu

Hi, Michael How can I deploy lava-scheduler-tool for the buildout lava instance? I tried with both the "python setup.py install" command and the lava-develop-local command, but neither seems work:( here is the console log I did: (buildout)17:06:56 liuyq:lava-scheduler-tool$ python setup.py install error in lava-scheduler-tool setup command: Unable to import 'lava_scheduler_tool': No module named lava_scheduler_tool (buildout)17:07:03 liuyq:lava-scheduler-tool$ cd ../ (buildout)17:07:06 liuyq:code$ pwd /srv/lava/code (buildout)17:07:07 liuyq:code$ lava-develop-local lava-scheduler-tool/ Determining egg name... lava-scheduler-tool + ln -sfT /srv/lava/code/lava-scheduler-tool /srv/lava/instances/buildout/code/r67/local/lava-scheduler-tool + /srv/lava/instances/buildout/code/r67/bin/rebuildout ++ basename buildout-development.cfg + /srv/lava/instances/buildout/var/lib/bootstrap-venv/bin/buildout -c /srv/lava/instances/buildout/code/r67/buildout-development.cfg Develop: '/srv/lava/instances/buildout/code/r67/.' Develop: '/srv/lava/instances/buildout/code/r67/local/lava-android-test' warning: no files found matching '.testr.conf' Develop: '/srv/lava/instances/buildout/code/r67/local/lava-dispatcher' Develop: '/srv/lava/instances/buildout/code/r67/local/lava-scheduler-tool' Installed /srv/lava/code/lava-scheduler-tool/versiontools-1.9.1-py2.7.egg Uninstalling manifest. Uninstalling server-symlink. Running uninstall recipe. Uninstalling wsgi. Uninstalling instance. Installing instance. Updating server. Develop distribution: lava-dispatcher 0.18.dev383 uses namespace packages but the distribution does not require setuptools. Generated interpreter '/srv/lava/instances/buildout/code/r67/bin/py'. Updating python. Develop distribution: lava-dispatcher 0.18.dev383 uses namespace packages but the distribution does not require setuptools. Generated interpreter '/srv/lava/instances/buildout/code/r67/bin/python'. Updating hack-py. hack-py: Running sed -i -e 's%^_interactive%import os; os.environ["DJANGO_DEBIAN_SETTINGS_TEMPLATE"] = "/srv/lava/instances/buildout/etc/lava-server/{filename}.conf"; os.environ["DJANGO_SETTINGS_MODULE"] = "lava_server.settings.debian";&%' /srv/lava/instances/buildout/code/r67/bin/py /srv/lava/instances/buildout/code/r67/bin/python Installing wsgi. Develop distribution: lava-dispatcher 0.18.dev383 uses namespace packages but the distribution does not require setuptools. Generated script '/srv/lava/instances/buildout/code/r67/bin/lava-server.wsgi'. Updating scripts. Installing server-symlink. Develop distribution: lava-dispatcher 0.18.dev383 uses namespace packages but the distribution does not require setuptools. Installing manifest. Develop distribution: lava-dispatcher 0.18.dev383 uses namespace packages but the distribution does not require setuptools. (buildout)17:07:23 liuyq:code$ lava-tool submit-job usage: lava-tool [-h] {auth-add,help} ... lava-tool: error: invalid choice: 'submit-job' (choose from 'auth-add', 'help') (buildout)17:07:42 liuyq:code$ -- Thanks, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android linaro-validation(a)lists.linaro.org http://lists.linaro.org/pipermail/linaro-validation

13 years, 1 month

← Newer
1
...
55
56
57
58
59
60
61
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation