[Fuego] How to add a Power-Controller and Console Server to FUEGO?

[daniel.sangorrin at toshiba.co.jp]

Hi Tim,

> From: Tim.Bird at sony.com <Tim.Bird at sony.com>
[...]
> > > > For the power-controllers, I sent a patch to Fuego that adds support for
> > PDUdaemon [1]. Unfortunately, it got
> > > stalled and never made it into Fuego. Perhaps I can revive that thread.
> > > > https://lists.linuxfoundation.org/pipermail/fuego/2019-
> > March/thread.html
> > >
> > > Thanks! I walked briefly through the thread and I find it reasonable to
> > > use PDUdaemon for this purpose .. It would be great if it gets revived!
> > >
> > > I think many will have this requirement ..
> >
> > OK, give me a bit of time and I will re-send the patches.
> 
> I don't recall why the patches stalled last time, but
> I'm committed to having Fuego support PDUdaemon, and I'm confident
> we can work out a solution.  

The main discussion was about where to put the power control abstraction [1]. At the moment, ttc functions are referenced from the base-board.fuegoclass script (ov_board_control_reboot). The problem is that to use all those functions from "ftc power-on" we would need to export a lot of variables required by Fuego.

Instead, I proposed that we demultiplex "ftc power-on/off/reboot" within "ftc", by using a switch on the $BOARD_CONTROL tool (e.g. pdudaemon, ttc, adb), and let scripts call ftc power control functions in a nested manner.

There was another element of discussion [2] related to including PDUdaemon in Fuego or leaving it outside. After talks with PDUdaemon's maintainer Matt, I think that leaving it outside Fuego (running on its own docker container) is more flexible, and easier to integrate and maintain.

> I have been wanting to avoid having
> Fuego manage the provisioning layer, but I think we need to add
> something for those users who don't want to install something heavy
> like LAVA.
> 
> I believe we kicked around some ideas for this last Fall that I thought
> were promising.

Yeah, you can see some of the ideas in the same thread as the PDUdaemon series [3].
We can discuss that during the Fuego jamboree.

[1] https://lists.linuxfoundation.org/pipermail/fuego/2019-March/003079.html
[2] https://lists.linuxfoundation.org/pipermail/fuego/2019-March/003040.html
[3] https://lists.linuxfoundation.org/pipermail/fuego/2019-March/003082.html

[...]
> > Your setup is probably closer to what we call "Serial" transport. In other
> > words, I believe that the console server provides you only with a serial
> > console, not a session where you can send or receive files to and from the
> > board.
> 
> Agreed.  The diagram is not complete.  If the board has telnet, then that
> implies networking, which was not in Daniel's initial diagram. 

I think that the telnet connection Heinrich was talking about is between the host and the console server.
For Fuego, the best would be to drop the console server and substitute it by a switching hub.
In the future, we may want to have ssh AND serial (e.g. for bootlogs). In that case, the console server can be useful.

> The most
> common transport used by Fuego is network-based (ssh), but others
> are available, and we could probably adapt an existing one to your use case
> if needed.
> >
> > If you can install your own software (e.g. serio) on the console server, then
> > you can probably use the the Fuego transport "ssh2serial". I believe that this
> > transport uses SSH to get to the console server and then uses "serio" to
> > put/get files through the serial port.
> > Tim: could you confirm that?
> Yes.  The key is that ssh needs to be able to execute serio on the console server,
> so it has to be an open system.  The group that was using ssh2serial was using
> a general computer system (I think a raspberry pi), so they could install the needed
> software on the intermediary machine.

The console server that he is using seems to provide some programming functionality but it doesn't look as generic as using something like a raspberry pi or a PC as intermediary machine.

> 
> > But as I said above, this is not the ideal setup or use case for Fuego. Fuego
> > works much better when it has direct SSH access to the board.
> 
> Any network access that provides command execution and file transfer
> are fine.  Most Fuego users use ssh and scp, but telnet and rcp or ftp
> would work.  There are some issues (mostly to do with performance)
> with using serial, or ssh2serial as transports, but they can be made to work
> in most circumstances.

I think that telnet is used just as a "remote serial" port that allows receiving serial port messeges remotely.

Thanks,
Daniel