Page Comparison

...

• devnet ← contains devnet repo and devnet executable

• repos ← contains directories with names aligned with the build

  • localnetdevelop: a develop Develop repo directory

  • mainnetreltest: a mainnet release testing repo directory (branches are those is the last release to may be develop or a combination of those in Develop and MainNet)reltest

  • rel: a release test directory (i.e. branches are those of a combination of those in MainNet and DevelopMainNet release)

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

...

1. 1. a built 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

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

3. 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.

...

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.