FIO DevNet Release Notes

References

AWS Management Console (amazon.com)

Devnet - FIO Operations

Devnet Testing (fioprotocol.io)

FIO DevNet Private Repository

DevNet Build, Deploy and Test Process

The DevNet build, and deploy process follows the LocalNet Release process (steps 1-4). See FIO LocalNet Release Notes. In addition, perform the following steps on the devnet master node to spin up the nodes, devnet-a, devnet-b and devnet-c. Note that this requires access to the AWS Management Console for the DevNet cluster.

The DevNet boot node, devnet.fioprotocol.io, has the following directory layout at /home/ubuntu,

• devnet ← contains devnet repo and devnet executable

• repos ← contains directories with names aligned with the build

  • localnet: a develop repo directory

  • mainnet: a mainnet release directory (branches are those is the last release to MainNet)

  • reltest: a release test directory (branches are a combination of those in MainNet and Develop)

Note that to run any commands using the devnet tool, a chain must be running. When running the chain using fio.devtools start.sh, a local cluster of three nodes is automatically started. In addition, devnet command may be scripted to

1. Stop and clean any running chains using fio.devtools/start.sh

2. Build, and install fio as discussed in FIO LocalNet Release Notes.

3. Start the chain and build the contracts (see above)

4. Using the devnet tool, upgrade the nodes, devnet-a, devnet-b and devnet-c.

   1. Stop all remote nodes using the command, ./devnet -f config.yml stop. Note that fio-nodeos is started on startup/boot of nodes

      1. For devnet-a, the config yaml file is a.yml

      2. For devnet-b, the config yaml file is b.yml

      3. For devnet-c, the config yaml file is c.yml

   2. Upgrade and start the nodes with the newly build nodeos using the command, ./devnet -f config.yml -bin <Install Dir>/bin/nodeos upgrade

      1. The FIO Install Dir is /home/ubuntu/fio/<Version Nbr>

      2. For devnet-a, the config yaml file is a.yml

      3. For devnet-b, the config yaml file is b.yml

      4. For devnet-c, the config yaml file is c.yml

5. Start fiotop (located in /usr/local/bin and in path so can be started from anywhere)

6. Run any tests from a client (also discussed in FIO LocalNet Release Notes) against the boot node IP

Fork Testing

The fork testing steps outlined in Devnet Testing (fioprotocol.io) provide an overview of the steps necessary to perform fork testing but are absent of a few details, specifically related to updating a node. Following are a few notes to clear up any confusion.

The DevNet environment consists of a boot node, hosting the FIO chain as well as three virtual BP nodes (block producers), and three remote nodes hosting six BP virtual nodes each. Fork testing involves the update of one or more of the BP nodes to determine if any change occurred in the core causing a fork in block production. At this time forking changes are known well in advance and involve the inclusion of a timestamp (date and time) at which block production will transition from one way to another, i.e., data stored in tables transition from using one set of columns to another set of columns. For the purposes of this discussion we focus only on how to upgrade the BP nodes.

As mentioned above fork testing involves updating one or more BP nodes. In the DevNet environment, a BP node may be solely a block-producing node or have plugins installed, i.e. chain_api, net_api, db_size_api allowing further capability. Regardless nodes in the DevNet environment are updated in groups of 3, or 6, and may be updated either by installing a new FIO Core and using fio.devtools to start the chain or by building an updated chain and using the devnet tool to ‘upgrade’ the remote nodes.

1. Build, install and run the current version of the FIO chain as described in FIO LocalNet Release Notes.

2. Stop and upgrade all remote nodes as described above in step 4.

At this point all nodes are running the same version of FIO.

1. Build, and install an updated version of the FIO chain as described in FIO LocalNet Release Notes.

2. Stop the current instance of FIO using fio.devtools start.sh, by nuking the chain

3. Start the updated instance of FIO using fio.devtools start.sh, with a new build of the contracts. Note, one may also run the updated chain, and apply the release script to update the contracts.

4. Using the devnet tool, upgrade one of the remote nodes as follows,

   1. Stop the remote node using the command, “./devnet -f config.yml stop”, i.e. ./devnet -f a.yml stop.

   2. Upgrade the remote node using the command, “./devnet -f config.yml -bin <FIO Install Dir>/bin/nodeos upgrade”, i.e. ./devnet -f config.yml -bin /home/ubuntu/fio/3.4/bin/nodeos upgrade

   3. Note, the upgrade command will push out a new nodeos binary to the remote server and that this may be accomplished without actually stopping the “old” chain.

5. Start fiotop (as fiotop is in the path, type fiotop and hit Enter).

6. Verify that the BPs continue to process blocks. Note that any stoppage will indicate a forking change. One may also montor the logs on any of the servers hosting block producers.

7. Run the smoke test from any client (against an api node, in this case the boot node).

8. Repeat this process for server b, i.e. the associated to b.yml.