Upgrading an Environment

Kaleido now provides the ability to upgrade environments to support newer levels of Geth and Quorum, as well as new features from the Kaleido team.

When a new release becomes available an orange circle with a white arrow will indicate the environment as upgradeable. Clicking the arrow displays a panel that provides more information about the upgrade and a confirmation dialog to initiate the rolling upgrade.

What you need to know about upgrading.

Upgrade currently only upgrades the Geth or Quorum node. It does not upgrade the environment to support new features provided by the Kaleido team.

A manual process listed below provides details how one may manually upgrade their environment to access new features.

The upgrade begins with the monitor node, then iterates through each node starting with the earliest deployed to the last deployed.

During an individual node’s upgrade, the node becomes unavailable for transactions.

Resilient Environment Upgrades

Rolling upgrades fortify the upgrade process, but users should ensure that their environments conform to the following sizing specifications to ensure the most uninterrupted upgrade possible:

IBFT environments should ensure 3F + 1 nodes are healthy at all times, where F is the number of failing nodes. Therefore in our current upgrade pattern there should be at least 4 nodes in each environment.

Geth Proof of Authority environments also requires a majority of validating nodes to exist before new blocks may be added to the chain. Therefore Proof of Authority environments should have at least 3 nodes.

Raft environments may continue to accept transactions as long as the minter/leader node stays online and leader election may continue as long as there are a majority of nodes running. Therefore Raft environments should have at least 3 nodes.

In short, Geth and Raft should have at least 3 nodes in the environment, while IBFT should have at least 4 nodes to safeguard network performance during upgrade.

What upgrade does not do

Currently the upgrade process does not deploy new accessory features for the nodes. One way to work around this limitation is for each node after upgrading the environment, deploy a new node after upgrade and then delete an existing node, until all the nodes in the environment have access to the new features.

Executing this process throws away the account keys for the old nodes, but new features become accessible.