7ace4293e9
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 |
||
|---|---|---|
| .. | ||
| contributor | ||
| install | ||
| user | ||
| conf.py | ||
| index.rst | ||