On Mon, 25 Jul 2016 09:29:28 +0200 Sjoerd Simons sjoerd.simons@collabora.co.uk wrote:
On Sun, 2016-07-24 at 14:29 +0100, Neil Williams wrote:
On Sun, 24 Jul 2016 00:21:34 +0200 Sjoerd Simons sjoerd.simons@collabora.co.uk wrote:
Hey all,
We've started experimenting with lava V2 jobs in our lava lab. Thusfar things are going well but it seems there is no ability to specify device tags nor to specific target device in V2 thusfar. Is support for those something that's still in the pipeline :) ?
Device tag support is a missing element from the V2 job submission schema. (It has support in the unit tests.) I'll get this into review next week and then into 2016.8, with some docs too.
Great thanks!
There is no support for submitting to specific target devices as this impedes both scheduling and lab management when needing to retire broken hardware.
Hmm, That's true though. Fwiw What I tend to (ab)use submitting to specific target devices for is mostly for hacking sessions and the likes when needing to do some maintaince or other aspects that really need one specific target device rather then any regular jobs. It would be nice to cover that use-case somehow.
Hacking sessions are for users though. As an admin, you already have direct access to the device. This was one of the reasons why V1 had all the device configuration on the dispatcher, so that local scripts could parse out the connection_command and power_on_cmd to get a way to get onto the device whilst it was Offline. (This is why we have maintenance mode on a per-device level.)
With V2, that information is available directly from the UI, so all the admin needs is take the device offline, ssh onto the dispatcher and have a web browser looking at the device detail page. No need to wait for the hacking session to be scheduled (another job could always get in first, even at high priority a health check takes precedence or there could be another high priority job already in the queue).
Just because hacking sessions log in a user as root, does *not* mean that this is a workable solution for administration - that confuses the issues. TestJobs, like hacking sessions, need to be ephemeral in terms of storage - that way admins can trust that users can't actually undo the admin setup just by using a hacking session themselves.