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

Tim.Bird at sony.com Tim.Bird at sony.com
Thu Jul 4 04:16:01 UTC 2019


> -----Original Message-----
> From: 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.

Yeah, that's not good.

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

I think my objection to this was that I don't want ftc to become some kind
of super-tool, and making it the abstraction layer for Fuego doesn't help
with defragmenting this layer across multiple tools.  We could start there,
and try to develop some ideas for handling the board management
abstraction with multiple different board management layers, to see what
shakes out as a good API here.

> 
> 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'm OK with this, as long as it's relatively easy to run (and I can do it from inside
or outside the Fuego container).  I do like having Fuego be a "batteries included"
system, so that someone starting from scratch doesn't have to go out and 
learn and integrate multiple systems just to get started.
 
> > 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.

Sounds good. Lets discuss all of this at OSSJ/ALS and FJ3.

Are you going to OSSJ?
 -- Tim


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

OK - that's right.  I didn't interpret that correctly.

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

I thought that might be the case.  It's not something you could ssh through.
For commands it might be possible to do some kind of telnet2serial transport,
but I don't think you could make file operations (get and put) work.

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

 -- Tim



More information about the Fuego mailing list