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.
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
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
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
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/
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
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/
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
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
Hi, All
In my afternoon, the jobs on staging failed to run due to the following error:
http://staging.validation.linaro.org/scheduler/job/34124/log_file
Traceback (most recent call last):
File "/srv/lava/branches/lava-dispatcher/lava_dispatcher/actions/boot_control.py",
line 63, in run
client.boot_linaro_image()
File "/srv/lava/branches/lava-dispatcher/lava_dispatcher/client/base.py",
line 365, in boot_linaro_image
self._boot_linaro_image()
File "/srv/lava/branches/lava-dispatcher/lava_dispatcher/client/targetdevice.py",
line 68, in _boot_linaro_image
self.proc = self.target_device.power_on()
File "/srv/lava/branches/lava-dispatcher/lava_dispatcher/device/master.py",
line 77, in power_on
self._boot_linaro_image()
File "/srv/lava/branches/lava-dispatcher/lava_dispatcher/device/master.py",
line 403, in _boot_linaro_image
boot_cmds = self.deployment_data['boot_cmds']
KeyError: 'boot_cmds'
I can run the jobs in my morning.
--
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