[Automated-testing] Looking for a Debian kernel provisioning solution

[Tim.Bird at sony.com]

> -----Original Message-----
> From: Paweł Wieczorek 
> On 16/02/18 19:47, Tim.Bird at sony.com wrote:
...
> > P.S.  Actually, I'll ask one question now.  I recently started using a
> > program called 'dlipower' to manage my DLI web powerswitch.  It's
> > written in python and talks to the power switch using an http interface.
> > Would something like this integrate into your system at some layer, or
> > does your system require the power management of a board to go
> > through MuxPi?  If it can fit in your system, where would it run?
> > That is, would your nanoPi be able to run the 'dlipower' command,
> > or would it run on the host?
> 
> In our system each target device gets its own supervisor (DUT-S: NanoPi)
> and controller (DUT-C: MuxPi):
> 
> .-----.-------.-------.
> | DUT | DUT-C | DUT-S +---+
> '-----'-------'-------'   |
>                            |    ________
> .-----.-------.-------.   |   /        \
> | DUT | DUT-C | DUT-S +---+---+ Boruta +--- etc.
> '-----'-------'-------'   |   \________/
>                            |
> .-----.-------.-------.   |
> | DUT | DUT-C | DUT-S +---+
> '-----'-------'-------'
> 
> Correct me if I am wrong - I assume that using DLI powerswitch would
> force DUTs to share a single controller:
> 
> .-----.-------.-------.
> | DUT |       | DUT-S +---+
> '-----+       +-------'   |
>        |       |           |    ________
> .-----+       +-------.   |   /        \
> | DUT | DUT-C | DUT-S +---+---+ Boruta +--- etc.
> '-----+       +-------'   |   \________/
>        |       |           |
> .-----+       +-------.   |
> | DUT |       | DUT-S +---+
> '-----'-------'-------'
> 
> Running "dlipower" commands could and should be done on supervisor
> (NanoPi), but target devices would no longer be independent. Board
> control is kept at DUT-C/DUT-S level and is completely separated from
> the rest of the stack (Boruta, Weles, Perun), so no further changes in
> any other layer would be required.
> 
> I hope that clarifies it. Do let me know if you have further questions.

I think that's right.  I'm not sure I would characterize it as
using DLI power "forces" the boards to use a single controller,
but rather that using a single power controller requires that
the DUT control software deal with mixing and matching
board control mechanisms from different hardware. 
It sounds like your 'Boruta' layer provides the abstractions
for this.

What is the division of labor between your control hardware
and your supervisor hardware (/software)?  From your
diagram I presume that Boruta is host-side software, and
that other software is running on the Nanopi and implementing
board supervisor functions?

Power is one dimension of board control.  Serial port is another.
Button presses are another.  Other buses (like USB or SDcard) are
yet another dimension of board control.  If I understand correctly,
MuxPi assumes all of these board control mechanisms are under the
control of a single piece of board control hardware (and software?).
This simplifies things because it reduces the number of connections
to the host for all these different dimensions of board control.
But it comes at the expense of requiring a uniform hardware control
system for the whole lab (and for all control dimensions).

Looking at your FOSDEM presentation, I like that you have some layers
identified, and are concerned with modularity (and KISS at each level).
But I'm not sure I understand each layer:

Perun - CI layer? (detect when to run, schedule jobs, interpret results)?
Weles - test execution layer?
Boruta - board control software layer?
MuxPI - physical layer

What is "Dryad" in relation to these?  I'm a bit confused by that.

Note: I can wait until ELC to hear the presentation myself and try to understand
it there.

I and writing some notes about board farm software
and wanted a placeholder name for your software.  I *think* that my 'ttc' (Tim's target control)
is roughly equivalent to your 'boruta' layer,  and 'fuego' is roughly at the
same layer are your 'Weles', but I'm not positive.  (and, just to complete
the comparison, I believe Fuego uses Jenkins for the functionality you
use Perun for, but we don't actually ship any provisioning functionality
or any of the Jenkins jobs for detecting CI triggers (e.g. when LTS gets
updated).

What would be a good name for the whole "stack"?  I've been referring to
it in my notes as either Samsung's stack or Pawel's stack, :-) , but is "MuxPi" the name
for the whole stack?  That's what it seems like from the slides.

Please let me know if I've misunderstood something here.
 -- Tim