Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add control plane #83

Open
hackaugusto opened this issue Dec 5, 2023 · 1 comment
Open

add control plane #83

hackaugusto opened this issue Dec 5, 2023 · 1 comment

Comments

@hackaugusto
Copy link
Contributor

Ideally services would be crash first, since that is th easiest model to work with. but unfortunately this won't serve all the servers:

  • the store creates in-memory representations of the trees, which will take a bit of time to create, so for that service it is best to avoid restarts
  • the rpc server works as a reverse proxy, restarting the service would close all client connections, which is not great for end-user performance
  • the current version of the block producer contains only in-memory store of transactions, so restarts would cause issues, eventually this will be lifted, but we should probably avoid losing in-flight transactions if we can

because of the above, we should have a way of managing the servers without requiring restarts. there are multiple ways this can be implemented:

  • watch dog over the configuration files, so when the file is written, the server reloads the configuration and applies the changes
    • this is nice and has a neat interface, but it can become an issue for cases were the user introduces syntax errors to the file
  • a control socket. this can be a unix socket (file socket), or a proper networked socket.
    • this is a neat approach, usually the socket is hidden behind a CLI program. it can be useful for settings that should not be persisted
  • system signals. like sigusr1
    • this is great to integrate the servers with process monitors, works well with systemd and other tools, but we have limited number of signals

I don't think any of the options above are ideal, usually a mix of each gives the best results

@hackaugusto
Copy link
Contributor Author

hackaugusto commented Dec 8, 2023

for file watching it seems the best option is notify, it is wildly used (see the docs). The only other option I found was watchman, but that requires an external service.

the only downside is that the api seems to be sync, so we should probably nave a file watching "service" running on a separate thread, sending events to the async tasks in tokia via channels. (note: we can make the service unnecessary by watching a single file, that would mean the configuration of all the services should fit in the same file)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant