[Fuego] [RFC] power-control for Fuego

Tim.Bird at sony.com Tim.Bird at sony.com
Tue Jul 9 07:54:50 UTC 2019


> -----Original Message-----
> From: Daniel Sangorrin
> 
> Hello Tim,
> 
> I have updated the power-control patches to the latest
> code (next branch). Unfortunately, I couldn't install
> the latest Fuego due to a "GPG error" in Debian. For
> that reason, the I couln't test the modifications.
> Please consider the patches only as "sketch" or
> "mud on the wall" for further discussion.
> 
> [PATCH] ftc: add power-control subcommands
> [PATCH] power-control: readme about pdudaemon and ttc
> 
OK - I think some of this stuff is worth having a face-to-face discussion about.

I'm going to brainstorm a bit in this message, so this might be a bit disorganized.

Taking a step back, here are the issues that I think we're trying to solve:
1) - Fuego doesn't have a board provisioning layer, which puts the burden on the
user to do this themselves.  That's not good.
2) - In order to build a provisioning layer in Fuego, there must be some interface
to a board control layer (ie a board control API)
3) - Fuego itself needs to use some board control APIS (e.g. reboot) in order
to perform automated recovery from test failures.
4) - we'd like to add support for an external board control layer, rather than
build our own, to avoid adding more fragmentation to the industry for this section
of the overall automated testing stack.

Here are some desired features:
 - ability to call different external board control layers, depending on the board
 - ability for a test to call board control functions
 - ability for ftc to call board control functions
 - ability for a human to perform board control functions (manually)
 - ability to isolate the board control details from callers
 - can store board control data in a single place (not replicate board control data in multiple layers)

I had started to do this by adding the BOARD_CONTROL variable, and fuegoclass
functions (shell functions), that ftc or a test could call.  However, that only allowed
the board control functions to be called in "Fuego context" - that is, Fuego had to
instantiate an entire Fuego test context in order to execute a simple control function.

Here's the old API:
 - nature: shell function
 - commands: ov_board_control_reboot() - no sub-commands or arguments
 - meta-data storage: in board file

The new API in the proposed patch is:
 - nature: command line (via 'ftc')
 - commands: power-on, power-off, power-cycle

> Q: should we use a separate python module?
> Q: should we use a board-control class with on/off/reboot
> operations?
I think these questions have to do with  the power driver API (ie, how does a new
power control layer plug into Fuego), rather than the power API (how does Fuego
invoke the control functions).

If that's true,  I would say:
 - I don't think we have enough board control systems that we want to support to warrant coming up with our own driver API - so doing something inline in ftc is OK

> Q: does the ttc function look OK to you?
Yes, I think so.

> Q: how do we move from here to the "board management
> abstraction" that you have in mind?

Well, I think our priorities are:
1 - support Fuego users' needs
2 - defragment the industry and move it forward

So, although  we are inventing a new layer (and thus a new API)
for power control, I think that It serves our first priority, which is to
get something that Fuego users need.  More specifically, a boot test
needs to do provisioning, which requires automation of the board
control layer, which requires an API.

One question, it looks like you kept: ov_board_control_reboot.
That is what ftc and one test (Benchmark.reboot) call.

What do you envision a Fuego boot test
(one that does board provisioning) would use:
 - ov_board_control_reboot()?
 - ftc power-cycle 
 - something else?

Is more needed for Fuego to do board provisioning?
ttc has things like 'get_kernel', get_config', 'set_config', 'kbuild',
and 'kinstall', to perform different operations during a kernel CI
loop.  Do you envision that we would add more commands in ftc
for these operations?  Or are you thinking we would implement
these other operations as separate Fuego tests, and string them
together with the equivalent of a batch test? Or is there some other
plan?

As far as the patch goes, I think this one looks pretty good, but I'll
comment on its details separately.
 -- Tim








More information about the Fuego mailing list