ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-27 08:22:35 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

ENT-1685: Add clarification of update process to README (#645)

Browse Source 
Add clarification of parameters update process to README
This commit is contained in:
Katarzyna Streich 2018-04-03 14:46:48 +01:00 committed by GitHub
parent d0cec8cabb
commit bba3721c86
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 30 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
network-management/README.md
View File

@ -271,37 +271,38 @@ Run the following SQL script to archive the node info table (change the timestam
# Updating the network parameters # Updating the network parameters
The initial network parameters can be subsequently changed through an update process. However, these changes must first The initial network parameters can be subsequently changed through an update process. However, these changes must first
be advertised to the entire network to allow nodes time to agree to the changes. be advertised to the entire network to allow nodes time to agree to the changes. Every time the server needs to be shutdown
and run with one of the following flags: `--set-network-parameters`, `--flag-day` or `--cancel-update`. For change to be
advertised to the nodes new network map has to be signed (either by HSM or by local signer).
The server needs to be shutdown and started with the same `set-network-parameters` flag as before but this time the network Typical update process is as follows:
parameters file must have `parametersUpdate` config block: 1. Start network map with initial network parameters.
2. To advertise an update:
* Stop network-management.
* Run it with ``--set-network-parameters`` flag. The network parameters file must have `parametersUpdate` config block:
```
parametersUpdate {
description = "Important update"
updateDeadline = "2017-08-31T05:10:36.297Z" # ISO-8601 time, substitute it with update deadline
}
```
Where `description` is a short description of the update that will be communicated to the nodes and `updateDeadline` is
the time (in ISO-8601 format) by which all nodes in the network must decide that they have accepted the new parameters.
parametersUpdate { NOTE: Currently only backwards compatible changes to the network parameters can be made, i.e. notaries can't be removed,
description = "Important update" max transaction size can only increase, etc.
updateDeadline = "2017-08-31T05:10:36.297Z" # ISO-8601 time, substitute it with update deadline
}
`description` is a short description of the update that will be communicated to the nodes and `updateDeadline` is The process will exit, nothing will be sent to the nodes yet.
the time (in ISO-8601 format) by which all nodes in the network must decide that they have accepted the new parameters. * Start network-management as normal without any flags. This time, the nodes will be notified of the new parameters
update next time they poll.
3. Before the `updateDeadline` time, nodes will have to run the RPC command to accept new parameters.
This will not activate the new network parameters on the nodes. It is possible to poll the network map database to check
how many network participants have accepted the new network parameters - the information is stored in the `node-info.accepted_parameters_hash` column.
4. When the flag day comes. Restart network-management with ``--flag-day`` flag. This will cause all nodes in the network
to shutdown when they see that the network parameters have changed.
The nodes that didn't accept the parameters will be removed from the network map. The ones that accepted, will need to be manually restarted.
NOTE: Currently only backwards compatible changes to the network parameters can be made, i.e. notaries can't be removed, It is possible to cancel the previously scheduled update. To do so simply run:
max transaction size can only increase, etc.
It is possible to poll the network map database to check how many network participants have accepted the new network parameters
- the information is stored in the `node-info.accepted_parameters_hash` column.
When the time for switching the parameters comes, doorman should be restarted again, this time only with `flag-day` flag
(no parameters file).
```
java -jar doorman-<version>.jar --flag-day
```
This will switch the parameters that were previously advertised as an update to be the current ones in the network map,
however the new network parameters won't be active until the new network map is signed (either by HSM or by local signer).
All nodes in the network need to restart to apply the new parameters. Any node which has not accepted the new parameters
will fail to start.
It is possible to cancel the previously scheduled updated. To do so simply run:
``` ```
java -jar doorman-<version>.jar --cancel-update java -jar doorman-<version>.jar --cancel-update
``` ```