Hi.
I've just realized that we'll likely see issues when test images start
showing up as armhf. Our master image compiler that builds a few of the
tests is going to target armel.
I'd like to propose that we re-purpose the master image. I'd like to
_stop_ using it for building software. That is: all lava-test install
steps will be invoked in the _test_ image.
We can apply this without requesting our users to rewrite their test
scenario definitions. I'd like to propose rewriting the scenario file to
invoke any lava-test-install _after_ the boot test image step.
Thanks
ZK
--
Zygmunt Krynicki
Linaro Validation Team
Dave, I deployed the latest version of lava-dispatcher yesterday, which
included your changes to support vexpress. If you have a chance, could you
run a test job through it and make sure it's all working well?
Thanks,
Paul Larson
Hi
I'm trying to use my snowball for development testing. It seems that
having kernel command line specify ip=dhpc is evil as that makes all of
the userspace network configuration not to happen.
When this happens ifup scripts are not executed and ntpdate is never
invoked. I have not debugged this correctly yet but that seems to be the
case for me.
Thanks
ZK
--
Zygmunt Krynicki
Linaro Validation Team
Hi
I've looked at this blog announcement [1] and found it interesting.
Travis seems to be a build service optimized to work with, and
understand a load of dynamic languages. What I really like about it
how it makes the effort required to add CI to $my_pet_project very
very low. I like how they provide HTML snippets that show if your
project builds or not. I like how they display stats [2]. I like how
they are integrated with github (it probably makes sense for them but
the idea is that you loose another "config" mess - no separate login,
no separate repo setup). I like their UI [3]. They seem to support
building and testing branches of the single repo from github which is
also nice [4].
I know they are focused on CI (build and yes-or-no testing) but is
there anything else we could learn from them?
Thanks
ZK
[1] http://about.travis-ci.org/blog/announcing_python_and_perl_support_on_travi…
[2] http://travis-ci.org/stats
[3] http://travis-ci.org/#!/ruby/ruby
[4] http://travis-ci.org/#!/ruby/ruby/branch_summary
Looping in the linaro-validation mailing list. Nothing private here and
would like to get input from others as well.
On Mon, Mar 5, 2012 at 11:12 AM, Andy Doan <andy.doan(a)linaro.org> wrote:
> On 03/02/2012 11:50 PM, Paul Larson wrote:
>
>> On Thu, Mar 1, 2012 at 4:54 PM, Andy Doan <andy.doan(a)linaro.org
>> <mailto:andy.doan@linaro.org>> wrote:
>>
>> This email spans 3 areas and I wasn't sure who'd be interested. Feel
>> free to add people if you'd like.
>>
>> I just spent the day getting the coremark benchmark to run under
>> lava-android-test and wanted to share my findings and methodology.
>>
>> Neat!
>>
>> The key obstacle is that coremark requires a registered download. ie
>> - you can't just throw this in the Android build and let the world
>> use it. This is what makes the whole process trickier than normal
>> "androidify + lavaitize" something.
>>
>> Well, hopefully not too much. A couple of observations here. First off,
>> feel free to tell the LAVA team that you have a tarball you want to host
>> for download into lava, inside the lava infrastructure so that it will
>> be available to LAVA, but not outside. We have a similar situation with
>> the binary drivers needed for panda builds. The scripts that the
>> Android team put together were useful for getting started, but certainly
>> not something we'd want to work with since it required interaction.
>> What we ended up doing was building a tarball of everything it
>> installed, and hosting it inside the lab. We could do a similar thing
>> with coremark so that it's available for lava jobs, but not for public
>> download.
>>
>> We could merge something like this in lava-android-test, but if so, we
>> should include instructions in case anyone outside linaro wants to use
>> it. To use it, they would have to host coremark themselves since we
>> can't provide it. Another option is to do it out of tree, but while
>> lava-test supports out-of-tree tests, it so far hasn't been a priority
>> to push this feature in to lava-android-test since the current push from
>> Zach's team has been to include all their tests. I've expected that
>> there will eventually be some things like this where that's not really
>> possible though, and we have a blueprint to add out-of-tree support to
>> lava-android-test. If this is a model you would need, just let me know
>> and I can bump the priority on that.
>>
>
> My current code was done for maximum flexibility. It could be checked into
> lava-android-test, or we could keep it out-of-tree to avoid confusion for
> people who'd think they could easily run it. I'm leaning to out of tree,
> but don't really care.
>
> The question I'm thinking about now is about the job submission to LAVA.
> I'm thinking of an approach where we create a new dispatcher command that
> would be semi-generic for all restricted tests and look like:
>
> {
> "command": "lava_android_test_install_**restricted",
> "parameters": {
> "tests": ["coremark"],
> "install_options": ["coremark_url=http://user:**pass@1.1.1
> /coremark-linaro4.6"**]
> }
> },
>
> Why would it need a _restricted version of the command? I don't think
that's necessary.
> I have one security concern with this approach: Do we enforce any type of
> security about who can view the job definitions in LAVA? ie - if anyone
> could see the job definition then they'd be able to see how they could
> download the restricted file.
>
I don't think that's a problem. In fact, what I'm suggesting is to simply
have it available as a download from our NAS system in the lab, that is
behind the firewall and not exposed. You'll need to get us to put the file
there, but then it wouldn't need to be behind yet another layer of security.
In fact, as I'm thinking about this, I don't even see a need for an
out-of-tree test support in lava-android-test. The out-of-tree support is
needed in lava-test because it's getting reinstalled every time. With
lava-android-test, it could simply be a python module that we install one
time and update as needed, then that test would be available on our
server. If anyone else wanted to use it, they could, but would need to
specify their own location for getting the coremark binaries.
Thanks,
Paul Larson
