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

Tim.Bird at sony.com Tim.Bird at sony.com
Tue Jun 25 22:45:25 UTC 2019

> -----Original Message-----
> From: daniel.sangorrin at toshiba.co.jp
> > From: Heinrich.Toews at wago.com <Heinrich.Toews at wago.com>
> > On 19.06.19 02:47, daniel.sangorrin at toshiba.co.jp wrote:
> > > Hello Heinrich,
> > >
> > >> From: fuego-bounces at lists.linuxfoundation.org <fuego-
> bounces at lists.linuxfoundation.org> On Behalf Of
> > >> Heinrich.Toews at wago.com
> > >>
> > >> Hey altogether,
> > >>
> > >> at our company we are willing to use FUEGO for our Linux Kernel
> Testing.
> > >>
> > >> We already have installed Racks ready with our own MODBUS TCP/UDP
> > >> power-controllers and console servers interfacing with TELNET/SSH.
> > >
> > > I will assume that this is what you want to do, otherwise please let me
> know:
> > >
> > > [FUEGO HOST] --TCP--> [MODBUS TCP/UDP]--power on/off--> [boards
> under test]
> > >               `---SSH--> [Console Server]--serial port-----------^
> >
> > Yea, you're right that's exactly what I want to do!
> Oops I missed something important.
> Are the boards under test connected to a LAN?
> I ask that for two reasons:
> 1) You probably want to install the latest kernel and file system image before
> you start testing. For example, you can do that by booting from tftpboot, or
> you could use some more advanced solution such as LAVA. Both of them
> require a LAN connection.
> [Note] Alternatively, you can install the latest kernel/image manually.
> 2) You also need to install the tests that you want to run. Most Fuego built-in
> tests assume that there is a connection with the board to install test software
> (a transport layer). If you don't have such a connection, you will need to build
> your tests in your image and skip the build and deploy phase in Fuego (using
> ftc command arguments).
> > >> What would be the best practice to add such support to the FUEGO
> code?
> > >
> > > 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.  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.

> > > In parallel, could you check if PDUdaemon supports your power
> controllers?.
> > >
> https://github.com/pdudaemon/pdudaemon/tree/master/pdudaemon/driv
> ers
> >
> > A Modbus driver is not included yet but it would be an easy task to add it.
> OK, good.
> [Note] Another option is to add new BOARD_CONTROL type or override
> ov_board_control_power_xxx functions in your board file.
> > > For the console server, I guess that you can use the SSH transport
> support available in Fuego. I have never
> > used a Console server. Does it use a different SSH port for each of the
> underlying serial port connections?. If that
> > is the case, you will need to define the SSH_PORT on the corresponding
> board file at `fuego-ro/boards`. If you
> > are using different user names instead, then you would need to set the
> SSH_KEY or the SSH user and password
> > (LOGIN, PASSWORD) in the board file.
> >
> > Okay, thanks - I will try this. We are using ConnectPort LTS32 .. SSH
> > should be possible somehow. Until now we only used TELNET.
> SORRY, I was probably half-sleep when I said that. Probably, you CANNOT
> use Fuego's SSH transport because you are using serial ports on the boards'
> side.
> 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.  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.

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

More information about the Fuego mailing list