[Automated-testing] Call for agenda items for the Open Automated Testing Standard (OATS) call this Thursday Nov, 14th

[Jan Lübbe]

Hi,

On Wed, 2019-11-13 at 09:13 +0000, Milosz Wasilewski wrote:
> On Wed, 13 Nov 2019 at 01:49, Anmar Oueja <anmar.oueja at linaro.org>
> wrote:
> > We will be having our monthly OATS call this Thursday at 14:00 UTC
> > (call details [1]) Please respond to this thread with any agenda
> > items you wish to discuss. I suspect we have some Items post ATS
> > that could benefit from a verbal discussion.
> > 
> > If we don't have a clear agenda, I'm inclined to cancel the call.
> 
> I would like to talk about 'master scheduler' concept that came out of
> discussion on board management interface. We talked about this a bit
> at ATS and I did some experimenting with labgrid last week.

So far I've not found time to start with a prototype implementation.

I'm not completely sure that I'll be able to join the call, so here are
some comments.

> However I'm still confused on:
>  - how labgrid preserves state (locks, reservations)?

This is done by the "coordinator". This state is intentionally not
persisted over restarts of the coordinator (as clients would need to re
ynchronize their full state anyway).

>  - how is the serial/ssh data transported?
The clients connect directly to the exporters or to "static" serial
servers (to reuse existing user authentication via SSH, among other
tradeoffs). The coordinator only provides the necessary information and
change events.

>  - how to move devices between 'users'? Users in this context can be
> test tools (like LAVA, Fuego) or individual engineers. I have some
> vague idea on how this can be done and it would be nice to learn what
> others think.

So far I've not thought of test frameworks (where I'd include labgrid)
and individual engineers of being at the same level. Rather engineers
would be users for LAVA (via hacking sessions) or labgrid (i.e. via
labgrid-client).

My current idea is: The "master scheduler" prototype would talk to each
test framework and get their internal queue status. Then it would look
for queued jobs where the necessary boards/resources are currently
allocated to a different test framework. If they are idle there, it
would deallocate them there (whether via locking them or placing them
into a maintainance mode depends on the framework). Then it would
enable them in the framework that currently needs that board and let
the job progress to execution.

There would probably need to be some mapping of boards names between
the different framesworks.

I think that concept should work with the current implementations of
lava, fuego and labgrid. Then one could experiment with sharing boards
between frameworks, although the scheduling would probably be less
efficient than in a single framework.

Regards,
Jan
-- 
Pengutronix e.K.                        | Dipl.-Inform. Jan Lübbe     |
Steuerwalder Str. 21                    | https://www.pengutronix.de/ |
31137 Hildesheim, Germany               | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686        | Fax:   +49-5121-206917-5555 |