[Fuego] pdudaemon support for Fuego

[Tim.Bird at sony.com]

Thanks for working on this.  I have a few questions.
See below.

> -----Original Message-----
> From: Daniel Sangorrin
> 
> Hello Tim,
> 
> One of the results from the Automated Testing Summit in Scotland was
> an agreement on using pdudaemon to control PDUs (Power Distribution
> Units).
> 
> This patch adds such support:
> [PATCH] ftc: add a new command to interact with pdudaemon
> 
> This is a very short quickstart:
> 
> - Prepare pdudaemon (for an ip9258 PDU in this example)
> 
> host$ git clone https://github.com/pdudaemon/pdudaemon
> [Note] I have made a few changes and sent a pull request, so temporarily
> you may want to use https://github.com/sangorrin/pdudaemon
> host$ cd pdudaemon
> host$ vi share/pdudaemon.conf
> {
> 	"daemon": {
> 		"hostname": "0.0.0.0",
> 		"port": 16421,
> 		"dbname": "pdudaemon",
> 		"logging_level": "DEBUG",
> 		"listener": "http"
> 	},
> 	"pdus": {
> 		"192.168.11.68": {
> 			"driver": "ip9258"
> 		}
> 	}
> }
> host$ sudo docker build -t pdudaemon --build-arg HTTP_PROXY=$http_proxy
> -f Dockerfile.dockerhub .
> host$ docker run --rm -it -e http_proxy=$http_proxy -e
> https_proxy=$https_proxy -e NO_PROXY="$no_proxy" --net="host"
> pdudaemon:latest
> 
> - Check that it works manually

OK - I'm just trying to double-check my understanding of the situation here.
So, apparently the way to use pdudaemon is to build a docker container for it,
and communicate with the daemon inside that container via curl (that is, using
HTTP over a network). Is that right?

Would it make sense to clone the pdudaemon code into the Fuego docker container,
and start the daemon there, rather than in its own container? 

I can think of pros and cons to each approach.

Pros:
  * It eliminates separate steps for installing and starting the daemon (well, technically
      it would combine the steps with Fuego's container creation)
      * In this case, we might try to put the pdudaemon.conf into Fuego's fuego-ro/conf directory.

Cons:
  * It may be confusing to disable a Fuego-integrated pdudaemon, if someone already
      has one installed and is using that one (you might transfer the configuration to the Fuego
      instance of the daemon, or you might disable the integrated one and just configure
      Fuego to use the pre-existing one.

At the Automated Testing Summit, we didn't have time to discuss how to coordinate
how different pieces would fit together, particularly when they are in their own containers.
I'm not sure if this is something that needs to be done on a case-by-case basis, or if
there is some design pattern we should be following for this, that we want to encourage
tools to adopt to make this easier.

In the case of 'ttc', which provides similar functionality, it's integrated into the Dockerfile,
and into Fuego's transport layer.  And the IPC used is Unix command line invocation.


> 
> $ curl
> "http://localhost:16421/power/control/on?hostname=192.168.11.68&port=1
> "
> $ curl
> "http://localhost:16421/power/control/on?hostname=192.168.11.68&port=1
> "

Does the 'pdudaemon' project include their own command line utility?
If so, I'd rather use that than add something to Fuego.
 
> - Check that it works from Fuego
> 
> $ vi myboard.board
> 	PDU_HOSTNAME="192.168.11.68"
> 	PDU_PORT="3"
> $ ftc pdu -b myboard.board --command on
> $ ftc pdu -b myboard.board --command off
> 
> If you have any question about pdudaemon please let me know.

See above.
 -- Tim