threefoldtech
ZOS update over the chain.
Right now, ZOS basically syncrhoize its version with the hub. The hub is updated with a github action from within zos repo itself. Once a release is ready, a workflow is started to update the hub links to the right version for the main zos flist.
What is good about this, is that if the nodes got broken, or if the chain is down or if the node-chain integration got broken by accident it is still possible to revert or force update the nodes to a different version. Even if the node operation is broken.
It already happened multiple times that the node/chain relation got broken (invalid types, or other issues). I would be more comfortable to know that nodes can still be reverted even if the chain itself is down or broken. Hence I suggest the following:
- DAO will still decide what version to be installed
- A HUB workers that acts as a chain listener and runs on the hub with enough privileges to update the zos symlinks
- Once the worker receive the right event it will simply do the update (similar to what the github action do)
Benefits of this setup:
- This way, the DAO gets to decide what version to be installed, and it's fully automated
- Manual override is still possible (with the github action, or worst case manually)
- No changes is needed in zos, update procedure stays the same (against the version released on the hub)
- If nodes can't talk to the chain anymore, we still can force an update to fix that.
@LeeSmet @DylanVerstraete @xmonader