On Fri Apr 26 02:25:14 UTC 2013 Antonio Terceiro replied to me, but I wasn't on the list, so only just spotted it in the web interface...
> Non-API related thought: I think it is reasonable to have an internal >> file server to store disk images on that we create during builds >> without having to push up to snapshots.linaro.org and pull them back >> down. It makes far more sense to boot and test an image, then >> optionally upload it to the wider world. Let me know if we have this >> soft of temporary storage available. > We don't have something like this, but we probably should have one. >> I need to know if a machine is ready for me to use. I am happy to poll >> something. >> >> I need to tell LAVA/CI that I have finished with a machine. > If I understand correctly your asumption is to receive a interactive > session on the requested device(s), and then issue commands on it. Is > that correct? Yep Very similar to the LAVA hack tool that Tyler just demoed. > Maybe it's too late to ask this, but did you consider the possibility of > having the CI runtime produce "actual" LAVA jobs (i.e. a target device > spec + a non-interactive script), and then using an API to submit those > jobs, poll for their completion (or block until completion depending on > the use case) and acessing/manipulating/addressing the job results, > perhaps to use them as input for other jobs? I did consider a fixed function test approach, but for some jobs we are creating new commands based on the output of previous ones. It also restricts jobs to be a fixed sequence of commands unless you start implementing branches and loops in the test spec. Those are the reasons I chose Python - I don't have to re-invent anything. > This approach would have the advantage that since you don't directly > control the device, you don't have the need to tell LAVA that you are > finished with it. LAVA knows when the job you submited is done. Besides, > if a CI job crashes, LAVA won't stay forever waiting for being told that > a given device is done with, and doesn't need to care about handling > timeouts, and we don't need to worry about what is the right timeout to > wait for etc. > Does that make sense? Absolutely. I know that with all this added flexibility I am potentially making life difficult for us, but I think it will encourage adoption and is a nice, flexible method of doing some really powerful stuff. I am keen to mitigate the problems it creates as much as possible. I expect us to have jobs that specify a maximum runtime anyway (this is standard practice with lots of grid compute and cluster products). We should have a reasonably short default timeout for jobs that don't specify one to "train" users to do this right. That avoid the crashing issue to some extent. > OTOH, I realize that having the ability to reserve a device and receive > an interactive session on it is useful and would open up several other > possibilities, so I don't necessarily think it is a bad idea at all. -- James Tunnicliffe _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
