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
Vaultvisor: Vault Auto-Updater #310
Comments
I am not sure the updater should use subxt - it would become another piece of software that we may have to update if the runtime changes. I think it might be better to use a simple bash script that regularly polls storage using curl |
Related: interlay/interbtc#628 |
I think the overall goal is great. I'm wondering though how to best approach this. I've got the following questions:
|
Closed by #312 |
Is your feature request related to a problem? Please describe.
The vault client is released with breaking changes on a regular basis, forcing operators to check the docs website and manually update. This is both error-prone and inconvenient. Providing operators with an opt-in updating solution can ensure higher system availability.
This problem multiplies when an operator runs vaults on multiple networks, having to keep track of multiple releases.
Describe alternatives you've considered
Describe the solution you'd like
Implement Vaultvisor, a wrapper software similar to the Cosmovisor that listens for on-chain version release events and updates the vault client. Given a JSON file with input arguments, the Vaultvisor can run and auto-update binaries across the Kintsugi, Interlay, and their respective testnet networks.
set_vault_release(version, binary_checksum)
, which emits aVaultClientUpdate(version, binary_checksum)
event. The extrinsic writes to a storage item which is read when the Vaultvisor is first started up.subxt
to listen for theVaultClientUpdate
event. Based on the connected parachain network and the emittedversion
, it can derive the GitHub URI of the new release. Then, it:Additional Context
This solution requires releasing the vault client before a runtime upgrade is merged. JSON argument and rocksdb migrations would require their own script, with its own checksum stored on-chain.
Assumption: Sending a SIGINT signal to the vault process does not cause errors or side-effects.
The text was updated successfully, but these errors were encountered: