Thanks to Dave's work on cloud deployment, I've been able to move our
staging instance of LAVA off of our production server and onto a cloud
instance in our lab. In theory, everything should "just work".
However, I'm sure there will be hiccups. One thing I've noted is that
I wasn't able to get the old deployment-report.xhtml showing, and I
didn't have the patience to fight Apache conf files.
Currently people that are members of ~linaro-validation have access to
this new cloud node. If you need access let me know and I'll set
something up for you.
Also, I've backed up the old staging instance (to the usual place on
our NAS) and have deleted the instance from control.
Nothing like having an incompetent manager break everything while
headed into a weekend! :)
-andy
Dear all,
The time has finally come when our leased line is going to go live on validation.linaro.org!
We've scheduled with the supplier to do the switchover on Wednesday morning and, as long as things go according to plan, which they haven't so far, then the outage disruption could be less than 60 seconds. But the best laid plans of mice and men tend to go awry, and so I am sending out a warning that validation.linaro.org may be unavailable for up to 24 hours, because if nothing else, it will take time for the new IP address to filter through to all the name servers.
For those interested on the technical spec of the install, we have a 10Mb fibre connection on a 100Mb dedicated backbone, with the old ADSL connection acting as an automatic failover as a backup. We're being quoted 100% uptime, with penalties applied for any downtime. I've also been told that the 10Mb is flexible and it will allow us to peak above that but, if we do it too often, they'll warn us and then we can negotiate an up in the rate.
Here's looking to a much faster, more reliable LAVA interface to the world.
Thanks
Dave
------------------------------------------------------------------------
Dave Pigott
Validation Engineer
T: +44 1223 40 00 63 | M +44 7940 45 93 44
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
------------------------------------------------------------------------
On 17 Jul 2012, at 21:15, Ryan Harkin wrote:
> Hi Dave,
>
> 5) A5 and board naming.
>
> I was talking to Scott about all this earlier today. He is keen that we get this TC2 board up and running, but he's also keen that we replace one of the A9 core tiles with the A5 tile - now that the A9 has stabilised. This is a commitment we made to ARM a long time ago and I've been putting it off while we had 1 x A9 playing up on us.
>
> Scott and I discussed naming conventions and we were thinking that the numbering would be best on a per board type rather than overall vexpresses. Eg, we would have 3 boards:
>
> vexpress-a501
> vexpress-a901
> vexpress-tc201
Hi Ryan,
Now that I am close to having the A5 booting in the lab, we need to discuss this issue, as we did with the panda. Basically, with the panda, Scott and I originally settled on them having a common device type, with a device_tag of either 4430 or 4460, and then naming the device instances as pandaXX and panda-esXX.
However, this was later changed so that we have two distinct devices, panda and panda-es, since people will want to test on a specific platform, and know that they are, rather than the situation as it would have been, in that if you didn't specify a device tag, the job would run on any panda - 4430 or 4460. It was felt that this was less than desirable.
So what I'm suggesting is, that we create three device types, viz:
vexpress-a5
vexpress-a9
vexpress-tc2
And then it's clear when you submit a job it's clear which device type you will run on, rather than, as in the panda case above, submitting to vexpress and not knowing which type is being targeted.
N.B. I am aware of the need/desire to be able to submit one job to lava and then have it run across all device variants, but that is orthogonal to this argument since, if we do implement such a feature, a device set would probably be defined, i.e. rather than saying "one each of vexpress variants" you would specify "vexpress-a5, vexpress-a9, vexpress-tc2", or indeed "panda, panda-es".
Just to be clear, is that what you were suggesting as well?
Brickbats and suggestions?
Thanks
Dave
On 09/05/2012 11:17 PM, Prakash Ranjan wrote:
> And what does the image paramter contains? Is it containg any
> kernel image, or rootfs image or both?
>
> Can you please give tell me one example using a short job file.
>
The image parameter can be used if you have a pre-built image rather
than making the dispatcher run linaro-media-create on a hwpack+RFS.
Here's an example for qemu that can be applied to anything else:
<http://lava.readthedocs.org/en/latest/qemu-deploy.html#configure-the-dispat…>
I was recently looking at the LAVA documentation to see how much would
be useful for our latest member, Antonio. In short, our documentation
is pretty terrible (which we already new). I've spent most of today
trying to help get things a little better. Its by no means complete,
but I wanted to share with you where things are at, and what my future
plans are.
To begin with, I've changed up our wiki pages a bit. Part of this was
because of a request I got to move our pages from /Platform/Validation
to /Platform/LAVA. Part of this was to try and improve and remove. The
end results are:
A new main page: https://wiki.linaro.org/Platform/LAVA/
* the first few links here are purely for getting started with LAVA
* it includes a link to LAVA team oriented stuff:
https://wiki.linaro.org/Platform/LAVA/Links
Renaming of many pages under /Platform/Validation such as:
* https://wiki.linaro.org/Platform/LAVA/DevOps
A removal of LAVA documentation that's already covered in better
detail in our readthedocs pages.
Improvements to http://lava.readthedocs.org:
* updated information about our new lava-deployment-tool for install
* updated information on creating master images
* updated information on adding a device to LAVA
* a new page on how to add a QEMU device to LAVA
This is just the tip of the iceberg. The next things I need to look at are:
* the accuracy and importance of the wiki pages
* the accuracy of the readthedocs
I'll be trying to get this up-to-date as soon as possible. Please let
me know if you find an old page missing you used or something that's
out of date and I'll try and get it corrected.
-andy
Thought this might be of interest to everyone:
Now that Dave P has worked out all the hard stuff with OpenStack, I've
been spending some time the past few days getting all our new systems
provisioned. I thought this might be worth documenting, so I've created
a small wiki page explaining how I'm managing user accounts and DNS:
https://wiki.linaro.org/Platform/Validation/DevOps/ServerProvisioning
I think with the instructions there, just about anyone can add a system
to our lab that we can all go about using.
-andy
Hi Naresh,
Have you created a token to submit on v.l.o?
Thanks
Dave
On 4 Sep 2012, at 06:44, Naresh Kamboju wrote:
> Hi Lava team,
> please provide access to me to submit jobs from my local machine.
> where i could not added token. please do the needful.
> $ lava-tool auth-add http://naresh-kamboju@staging.validation.linaro.org/RPC2/
> Paste token for http://naresh-kamboju@staging.validation.linaro.org/RPC2/:
> ERROR: Token rejected by server for user naresh-kamboju.
>
> Best regards
> Naresh Kamboju
