References

AWS Management Console (amazon.com)

Devnet - FIO Operations

DevNet Testing

FIO DevNet Private Repository

Building the DevNet tool

Clone the dapixio DevNet repo located at dapixio/fio-devnet: devnet remote node management tool (github.com).

As this is a private repo, you will need to be granted access as well as have either a GitHub Personal Access Token or other means of ‘cloning’ the repo. If using an access token, the clone url is as follows:

Refer to git - Clone A Private Repository (Github) - Stack Overflow for guidance.

Once the repo is cloned, cd to the fio-devnet/cmd/devnet and execute the cmd, 'go build'. This will build the devnet executable.

These steps were performed on a machine with all the necessary dependencies, i.e. go, c/c++ compiler.

DevNet Environment

The DevNet environment consists of 4 nodes; the boot node as well as three remote nodes. The boot node is similar to a LocalNet (a local testing node) where an instance of FIO is built and executed using fio.devtools, acting as a 3 BP chain. The remote nodes are slave nodes, managed by the boot node via the “DevNet” tool; pushed a “release”, execute and register as 6 BPs, and produce block. These 4 nodes make up 21 Block Producers, similar to a TestNet or MainNet.

Refer to https://fioprotocol.atlassian.net/wiki/spaces/FO/pages/114131133 for an overview of the DevNet environment.

DevNet Testing

Devnet Testing

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; to start (and stop) the DevNet cluster - see Devnet - FIO Operations.

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

  • develop: a Develop repo directory

  • reltest: a release testing repo directory (branches may be develop or a combination of those in Develop and MainNet)

  • rel: a release directory (i.e. branches are those of a MainNet 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 virtual nodes (three nodeos processes, each using a separate port) is automatically started. In addition, one may script the following process;

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

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. The boot node, uses the default install process and fio.devtools to run 3 BPs, The remote nodes, are updated using the devnet tool and host 6 BPs each. Regardless the boot node is updated by building and installing a new FIO Core and using fio.devtools to start the chain and the remote nodes are updated using the devnet tool to ‘upgrade’ them (from the boot node).

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 if necessary, using the previous contracts version, then 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.

Setup and Deployment (Cut from https://fioprotocol.atlassian.net/wiki/spaces/FO/pages/114131133 to reduce duplication in readme, wiki, release procedures)

See Github Readme for usage documentation: https://github.com/dapixio/fio-devnet

‘devnet’ itself is a command-line tool for remotely managing a remote node, intended for use on distributed development networks. Currently, our default setup consists of a primary node and 3 cluster nodes across multiple regions on AWS.

example-config.yml -

Faucet Key: 5KF2B21xT5pE5G3LNA6LKJc6AP2pAd2EnfpAUrJH12SFV8NtvCD

Using the default initial install is fine but remember to use the devnet update command before starting the cluster nodes.

Fork Testing

Checkout the branch you’re attempting to test, build and install using the scripts provided inside the fio/scripts directory. Once the new fio core has been installed run the following commands on 1 or more nodes:

This command will stop, update, start and resync the node. To verify syncing, check the nodeos log file located on each node.

Contract Deployment

Updating contracts is the same on devnet as it is when updating on a local dev launch. Use fio.devtools and under the Post Actions, select Update All Contracts

This will use the eosio permissions and update the contracts to the checked out branch inside the ~/fio.contracts directory.