The current CogServer code base includes a server for managing MindAgents. This part of the code is effectively obsolete: its more-or-less unused, and more-or-less unusable. "More or less", because the Attention allocation subsystem still uses it. The MindAgent server subsystem needs to be removed from the CogServer, and refactored/redesigned into it's own component.
OpenCog has a general, unsolved system management problem. We want to provide users with some way of starting and stopping various different subsystems, possibly on a distributed network of machines. We want to be able to easily find and load the correct dataset or datasets (the "memories" and "knowledge" of the system), to checkpoint the system, in case it crashes, and to save partial or final results. We want to manage the configuration of the system. We want to allow the user to make sure that the appropriate systems are not starved for CPU time, and to monitor overall system performance. Finally, large parts of this need to be automated and automatable, so that the attention allocation subsystem can control overall resource scheduling. The network server, the agent server and the config file are three parts that currently implement what we've got. However, they are inadequate, and need to be replaced by a more powerful, better solution for managing and controlling the system.
(So, for example: We've got no way at all for managing data, and we've got no control panel at all. I use the command line to copy files around, and use 'top' to examine running processes, and 'iotop' and 'iostate' to stare at disk utilization. I use 'tmux' and 'byobu' to avoid loosing running sessions, and I use 'ssh' for remote login. This is OK-ish, for now, but is not scalable to more than 2 or 3 different machines. If I had to manage ten machines with ssh, byobu, top, and copy around datasets by hand, start and stop cogservers by hand, load and save datasets by hand, it would be a nightmare. It will need to be automated, eventually.)
Ideas: FWIW, there is a large variety of cloud management tools and systems, and perhaps OpenCog could pick and work with one of the smaller and simpler ones? We don't want to reinvent the wheel, here.