On Mon, Apr 25, 2016 at 01:51:00PM +0100, Milosz Wasilewski wrote:
On 25 April 2016 at 08:50, Daniel Thompson daniel.thompson@linaro.org wrote:
On 25/04/16 07:56, Neil Williams wrote:
On 24 April 2016 at 18:03, Leo Yan leo.yan@linaro.org wrote:
Hi there,
When I run LAVA hacking session on Juno but found sometimes Juno cannot be allocated IP properly:
- I created multinode definition for Juno:
Is there a reason you are trying to log into both sides of a multinode job?
I started discussing this with Luca last Thursday and I have a draft mail describing things a bit more:
As part of Leo's work for one of the members we would like to interactively run some tests on Juno.
We think the ideal structure looks pretty much like the one below:
+------------------------------------------+ + | | | | +--------------+ +-------------+ | | | | Orchestrator | ssh | | |Leo +---------------> (lisa or +---------> Juno | | | | | workflow | | | | | | | automation) | | | | + | +--------------+ +-------------+ | China | KVM Target | Firewall | lava-lab | | | +------------------------------------------+
Some observations and rationale:
- Leo needs to be able to interact with the software running on the Orchestrator via a http:// (or maybe https://) socket. An SSH tunnel with port forwarding is a good way to achieve this since then the web socket can be bound to the lo interface. This is what drives the interest in running this setup as a hacking session.
Is this automated or manual setup? If it's manual, why using LAVA?
It's a manual setup, and I want to use web browser on my local laptop to connect Orchestrator and can change testing case for ipython script frequently for EAS profiling.
I have no Juno board loacally so must use one Juno in LAVA lab.
- That software will, in turn, perform lots of scripted interaction with the Juno. The volume to interaction between orchestrator and target means they need a relatively low latency. This is why we avoid the simpler approach of running the orchestrator from home and having a single-node hacking session.
we already have this covered with Workload Automation and android benchmarking. WA supports ssh based connections for 'linux' targets. I guess lisa works in similar way. So what you need (assuming this is automated not manual setup) is to start session on KVM (host), start session on Juno (target), pass IP address from target to host, setup lisa to connect using this IP and run your testing. During this time target will wait for the host to signal 'testing finished'. Please check wa2-lava repo for examples:
Thanks for pointing. This will be helpful for later's automatic testing, as first step I can accept to do some steps manually to just make thing to work well, but definitly I should move on to automatic method as possible :)
The orchestrator is a moderately complex python code base which Leo has installed in a VM.
The orchestrator needs to run in a sufficiently secure environment for it to locally hold the means to authenticate itself to the Juno.
For anyone deeply interested the software stack on the orchestrator is lisa from ARM. lisa consists of a bunch of useful python code glued together with jupyter (nee ipython). It is a good tool to build complex but ad-hoc investigatory tests.
Other tools such as ARM's workload-automation and (so I hear) some of the OE testing environments can be deployed to the lab in a similar fashion using multi-node jobs. However AFAIK neither of these tools needs an interactive link between the job owner and the VM.
Daniel.
You won't be able to use the pass information between the two
nodes using the multinode API as that requires signal handlers in the dispatcher codebase. More likely you just need one side of the job, in which case you already have that working.
https://validation.linaro.org/scheduler/job/845471.0: this definition is to launch kvm so I can run testing suits on it; https://validation.linaro.org/scheduler/job/845471.1: this definition is to launch "deploy_linaro_image" on Juno board;
After launched these two images, the kvm usually can work well and I can smoothly log in it with ssh;
But for juno board, it will have below log for ssh:
Not all OpenEmbedded images can support a hacking session. Some require extra scripting - maybe done in a test shell which is defined before the hacking session-oe is invoked. This is a test shell problem, not a device problem. The device itself has raised an IPv4 address during the master image stage.
For whatever reason, the OE image provided failed to request an IP address after bringing up the interface https://validation.linaro.org/scheduler/job/845472/log_file#L_375_3
So finally I cannot get the info for Juno's IP and cannot log in it with ssh. It's not everytime I can reproduce this failure, so sometimes it's lucky so I can get a correct IP.
You need to investigate this within the image you are using and identify what steps are needed to fix the image. It may be that you need ifdown and then an explicit ifup or a different image.
As a workaroud, I found if I create two saperated definitions for Juno and kvm independently, then Juno's IP issue can be resolved:
https://validation.linaro.org/scheduler/job/845552 https://validation.linaro.org/scheduler/job/845561
So could you help give suggestions for this?
What are you trying to achieve with a multinode hacking session? You have a working singlenode hacking session on a juno, adding a KVM which you won't be able to talk to in the same way as a multinode job probably doesn't help with anything useful.
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users