41 lines
1.4 KiB
Markdown
41 lines
1.4 KiB
Markdown
|
|
||
|
|
## Units Config
|
||
|
|
|
||
|
|
- zinit is using unit files (which describes a service)
|
||
|
|
- the functionality described here allows zinit to reconfigure itself so we can always get out of issues
|
||
|
|
|
||
|
|
there are 3 main reasons to have this functionality
|
||
|
|
|
||
|
|
1. debug/development (only if debug flag is set in config)
|
||
|
|
2. fallback/disaster recovery
|
||
|
|
3. bootstrap, for the first initial setup, a node will receive the required setup in zinit, e.g. connect to farmingpool...
|
||
|
|
|
||
|
|
in normal mode the zinit will contact the registrar once an hour and check if there is something to be done.
|
||
|
|
|
||
|
|
there are 2 modes
|
||
|
|
|
||
|
|
- maintenance: check every 1h
|
||
|
|
- active: check every 5 sec
|
||
|
|
|
||
|
|
some prinpciples
|
||
|
|
|
||
|
|
- each instruction given to zero-os needs to be properly signed by the required amount of registrars.
|
||
|
|
- each instruction is a openrpc instruction where we use the openrpc return mechanism as described in [openrpc.md](openrpc.md).
|
||
|
|
|
||
|
|
## available instructions
|
||
|
|
|
||
|
|
- method_name: mode_active
|
||
|
|
- params:
|
||
|
|
- enddate : int (epoch time when to switch to maintenance mode, can never be longer than 2h)
|
||
|
|
- nothing to return
|
||
|
|
- method_name: zinit_list
|
||
|
|
- returns list of all units (service files) and their status
|
||
|
|
- method_name: zinit_set
|
||
|
|
- set a zinit unit file (service file) with all possibilities (see zinit specs)
|
||
|
|
- method_name: zinit_delete
|
||
|
|
- name of the zinit unit file
|
||
|
|
|
||
|
|
## implementation
|
||
|
|
|
||
|
|
Have a driver which uses zinit, keep zinit small, do in V.
|