Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation and Context
Because Horust is designed to be run inside containers, one could handle the lifecycle by for example restarting the docker container. In some cases, instead of restarting the whole container, one would want to restart a single service - or inspect its status etc. This PR will add support for horustctl, a command line that will allow to interact with horust.
Issue: #31
Description
I've reorganized the project to have three crates. Horust and horustctl are the two binaries. The interactions is accomplished using Unix Domain Sockets (UDS) and using Protobuf for the message definition. The Commands crate implements the required code and testing to use the uds.
On startup, Horust will create a new socket (and its folder if doesn't exists) in
/var/run/horust/horust-<pid>.sock
. This will allow using multiple horust instances on the same machine. The folder is configurable on both server and client.On client side, if no pid is specified horustctl will automatically search the folder and pick the only socket. If more than one socket is available, the command will fail.
I've decided to use protobuf3 for the definition of the messages, it turns out is quite verbose at least in rust, because all the messages are optional by default. If anyone wants to implement their own horustctl / client, they can reuse the protobuf.
I've considered adding tokio, but it's not worth bringing the runtime in just to handle this part of the program. There are also few interactions expected with this api, so I don't foresee performance issues.
The interactions are one shot: send a request, close the write socket, read the response. At least for now I don't have use case in mind that would require further interactions on the same connection.
I've also included the generated messages.rs module just to make browsing easier, I guess it's not a best practice to include generated files, but I don't see drawbacks with this.
Design
For now, the status works but It's still missing the update part. I'm thinking of merging the current changeset, and create a new pr to add the update part which seems a complicated change by itself.
For the status, now it just reports the status of the services. But I'm wondering if more info could be added.
Like:
Again, I'm thinking of merging this changeset and create a new pr.
How Has This Been Tested?
in one terminal:
in another terminal:
I've also added relevant integration tests.
Types of changes
Todo: