[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