virtualbmc/requirements.txt
Ilya Etingof 7ace4293e9 multiprocess server, ZMQ-based management cli tool
Original design of the VirtualBMC tool was that user manages
config files for individual VirtualBMC (via a cli tool), then
requests the tool to start the instances representing
individual VirtualBMC instances (via the cli tool). Then
the instances become independent processes. The only way
to know their whereabouts is through the pidfiles
they maintain.

There were certain practical inconveniences with the
original design, namely:

* Cumbersome to start/stop/monitor free-standing
  vBMC instances processes
* No two-way communication between the parent process
  and the VirtualBMC instances what makes child state check
  or modification unnecessary difficult

This commit turns server part of the tool into a single
process spawning multiple children processes and herding
them via ZMQ client/server.

The parent process runs server part of the control
interface, maintains persistent VirtualBMC instances
configuration and ensures all its children are alive
and kicking. Each VirtualBMC instance is still a separate
parent fork.

If child dies, parent respawns it right away. If parent
is about to die, it tries its best to kill all the
prospective orphans.

This new implementation tries to stay compatible with
the original one in part of `vbmc` tool CLI interface
and behaviour. Whenever it can't connect to the `vbmcd`
it tries to fork and spawn the daemon behind the scenes.

While the threading design for this tool might look better,
the underlying pyghmi library is apparently rather
complicated to use its concurrency capabilities reliably.
The other minor consideration is that running multiple
processes leverages CPU-based concurrency.

Other changes:

* The `start` command now accepts more than one domains
  to be started

Change-Id: Ie10f4598c7039a7afa9b45d01df3b3c3db252c1d
Story: 1751570
Task:  12057
2018-05-11 17:29:47 +02:00

11 lines
389 B
Plaintext

# The order of packages is significant, because pip processes them in the order
# of appearance. Changing the order has an impact on the overall integration
# process, which may cause wedges in the gate later.
pbr!=2.1.0,>=2.0.0 # Apache-2.0
six>=1.10.0 # MIT
libvirt-python!=4.1.0,>=3.5.0 # LGPLv2+
pyghmi>=1.0.22 # Apache-2.0
cliff!=2.9.0,>=2.8.0 # Apache-2.0
pyzmq>=14.3.1 # LGPL+BSD