Make Slave Manager Intelligent #24
Labels
Comments
This was referenced Dec 3, 2018
DavidPL1
added a commit
that referenced
this issue
Dec 12, 2018
In this commit many things happened, but due to the major change of the structure I just squashed everything to one feature commit. First of all the server/client model was updated according to #24: slave instances now run as a limited version of a master server, keeping track of their own local components. The master server starts a new slave managing socket server, that listens for new connections of slave servers and sends and receives serialized commands over the socket connection. The logging model has been changed fundamentally too (#26). The demo example with start all and an opened interactive cli gui generates the following structure: /tmp/Hyperion/log/ ├── hyperion-vm │ ├── client │ ├── component │ │ ├── nav@hyperion-vm │ │ │ └── latest.log │ │ └── top@hyperion-vm │ │ └── latest.log │ ├── server │ ├── slave │ │ └── Hyperion-DEMO.log │ └── standalone ├── localhost │ ├── client │ │ └── 13-39-08.log │ ├── component │ │ ├── roscore@localhost │ │ │ └── latest.log │ │ ├── xclock@localhost │ │ │ └── latest.log │ │ └── xeyes@localhost │ │ └── latest.log │ ├── server │ │ └── Hyperion-DEMO.log │ ├── slave │ └── standalone └── remote └── slave └── Hyperion-DEMO@hyperion-vm_13-38-57.log The log directory holds 3 types of directory on the first level: 'localhost' for commits from locally started components, 'remote' for remote logs that are copied over and 'HOSTNAME' which is an sshfs mount pointing to a slave machines /tmp/log/Hyperion/localhost directory. Inside the localhost directory are directories for each (non-trivial) run mode and a directory for component logs. In summary this commit provides all initially planned functionality for the interactive gui. The PyQt gui will be updated soon and a web ui is planned too. From here on the focus is shifted from new feature developement to bringing more stability. Fixes #27, #26, #23, #24
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Squashing multiple component configs into a single slave config and enhancing the slave session to behave like the master session, while communicating to its master over a single TCP port could minimize the traffic between hosts.
Sharing log files, host and component request would get a lot easier and keeping a master ssh connection and pinging the host on every monitoring thread cycle would be obsolete.
Concept graphic:
The text was updated successfully, but these errors were encountered: