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

[Paweł Wieczorek]

On 22/02/18 20:48, Tim.Bird at sony.com wrote:
>> -----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.

Agreed. I focused on supplying power and assumed basic DUT-C would cover 
this feature only.

> 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?

You are correct on Boruta being host-side software. It only schedules 
access to Dryad, i.e. DUT controlled by DUT-C (MuxPi board) under DUT-S 
(NanoPi) supervision (like DUT/DUT-C/DUT-S modules from my previous 
message).

Control hardware (MuxPi) takes care of physical aspects of DUT 
management (switching power supply, jumpers/buttons etc.) while 
supervisor provides connection to the DUT and abstraction for DUT 
management actions (e.g. dut_boot, dut_exec commands - additional 
software on NanoPi).

> 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?).

Correct - combining all of it and providing a unified interface is 
MuxPi's primary purpose.

> 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).

That's right. Once DUT becomes part of a Dryad and is fully configured, 
it can be controlled in a uniform way like every other target in the 
laboratory.

> 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.

Almost correct:

Perun - CI layer + dashboard (results interpretation and presentation)
Weles - testing framework: translates YAML job definition to actions to 
be executed, requests Dryad access from Boruta, runs actions on granted 
Dryad, collects results and artifacts
Boruta - Dryad access scheduler: grants access, provides SSH tunnel to 
DUT supervisor
Dryad - module combining DUT-S (NanoPi), DUT-C (MuxPi) and proper DUT

> 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.

MuxPi is the basis for the whole stack. It was initially a separate 
project. Other components came because we wanted to automate interaction 
with it. Since those layers got their names from Slavic mythology, the 
whole stack is called SLAV ;)

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

All the best,

Paweł Wieczorek
Samsung R&D Institute Poland
Samsung Electronics
p.wieczorek2 at samsung.com