[Fuego] [RFC] power-control for Fuego

daniel.sangorrin at toshiba.co.jp daniel.sangorrin at toshiba.co.jp
Wed Jul 10 03:01:36 UTC 2019


> From: Tim.Bird at sony.com <Tim.Bird at sony.com>
> > From: Daniel Sangorrin
[...]
> > 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.

Yes, for compatibility reasons and because it can be overwritten on the board which gives some extra flexibility.

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

I think that nested ftc is the most powerful approach. However, I think that tests should be using a single shared shell library. The main advantage is modularity. For example, you could re-implement the functions in the shared shell library to reuse tests in a different framework. The second advantage is that error handling code can be shared. For example, if tests call ov_board_control_reboot, ov_board_control_reboot will take care of ftc power-cycle errors (although my initial patch didn't have that error handling code).

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

I like the idea of stringing operations into a single shell or python script.

This script would be calling various commands:
  - linux commands: curl, wget, make, ...
  - ftc commands: power-cycle, expect-do on serial port, gen-report, post to squad/fserver/kernelci...

# In LAVA this is done in YAML in a declarative way. But Fuego uses the imperative approach, which I think is less elegant but easier to understand and more flexible.

I think that we want to have ftc commands for some operations and tests for others:
  - ftc commands:
      - power control commands
      - expect-do on serial port: this would be use to wait on the serial port for u-boot and then download the kernel or device tree by writing tftpboot or setenv commands to the serial port.
      - cp a file to or from the board
      - execute a command on the board
      - login to provide an interactive session (e.g. after the test fails)
  - tests:
      - kernel build and deploy: we already support deploying to a local dir, a server or to the target i think..

I would say that build tests are not really essential. They can be done on the single shell script (make -j8) or using a separate build tool (buildbot or jenkins itself). The important thing to me is that the shell script needs to know where the build artifacts are.

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

OK, thanks.
Daniel

>  -- Tim
> 
> 
> 
> 
> 



More information about the Fuego mailing list