On Mon, Apr 25, 2016 at 08:52:39AM +0100, Daniel Thompson wrote:
[...]
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.
One more question, the kvm will only boot with a text console. So bind web socket with lo interface, we can launch web browser within kvm itself. So should we bind web socket with kvm's eth0, and then use my local PC to remote access Orchestrator with http://?
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.
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.