...

AWS Management Console (amazon.com)

Devnet - FIO Operations

Devnet Testing (fioprotocol.io)

FIO DevNet Private Repository/wiki/spaces/FO/pages/114131133

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:

git clone https://<Personal Access Token>@github.com/dapixio/fio-devnet.git

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 /wiki/spaces/FO/pages/114131133 for an overview of the DevNet environment.

DevNet Testing

https://dev.fio.net/docs/devnet-testing

DevNet Build, Deploy and Test Process

...

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, devnet command may be scripted toone 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

...

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

...

/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

...