W dniu 16.02.2011 15:10, Paul Larson pisze:
Another crazy option would be to expose LAVA Job Dispatcher
directly and allow people to run jobs. In this case one job
I hope you don't really think this is a crazy idea, because it's
*exactly* what we discussed doing, and I think it is still the direction
I did not give it much thought when I wrote that email but I think the
direction is sensible and would be much more flexible than anything
else. After more conversations and some experiments I think this is the
way forward for all testing.
forward. Even back at the sprint, we talked about the fact that though
we don't know exactly what our android images will look like yet (so
specifics are hard to plan around), we do have a pretty good idea that
things like abrek are not going to be a good fit there. Additionally,
there are other tests that may eventually need to run from the outside.
For that matter, the boot test itself is exactly one of those things.
If a system doesn't boot, we still want to capture the serial log and
save it for later debugging. We certainly need, and have already
discussed the fact that the dispatcher has a server component that
drives execution of such things. This isn't, in any way, bypassing the
dispatcher, but rather using a different interface of it to run a
non-abrek based test.
Yeah, when you mentioned this now I started thinking. Do we really need
a daemon-like component for the dispatcher in general or just in the
farm environment. Can we assume that having the implementation the
"daemon" can be replaced with a command line tool that simply interacts
with one device - strictly for development purpose? I'm thinking about
stuff like volatile device state and device monitoring requirements.
Other than that it seems that our device overwatch + dispatcher looks
quite similar to android debug bridge. I think this is good.
Thanks
ZK
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
