To lay out the requirements for the initial RChain test net.
The test net is very much akin to a beta system, where users can interact with features before they hit production.
To demonstrate performance of the system to the community.
Create an environment where dApp developers can begin testing their applications.
Number of nodes
The initial test net should comprise of approximately 12 nodes. This is an arbitrary number.
The test net needs to have at least 1 bootstrap node in each geographical region to support the network.
Physical Ubuntu Linux Nodes - 4
Physical Centos Linux Nodes - 4
Docker Nodes - 4
Physical machine requirements
4 GB RAM
Physical storage - default is fine - 50 GB Henry Till I don't think we need much - please confirm.
Nodes should exist behind a router that can be configured to blacklist inbound IP address to shield against DOS attacks.
Bootstrap nodes have to have a static IP address.
Monitoring & DataCenter
The node software will have the necessary metrics to support monitoring of the node health. In addition to remote monitoring, there needs to be monitoring of the physical system.
Monitoring will send alerts in the event of an issue.
There is a team of NOC engineers monitoring the bootstrap nodes.
The bootstrap nodes have an uptime SLA of 99%, so that nodes can join the test net.
Security of the physical system - Rack location is secured via badge access or equivalent.
Personnel are available to address any hardware issues on the systems.
Nodes should be deployed as following:
United States - Utah - 12 Nodes -(1 of which is a bootstrap)
Deployment of Software Updates
The RChain software is available in Debian, rpm packages and Docker images. These nodes must be configured using these packages and images. The packages have a built in update mechanism. Updates on each node will take place in the following fashion:
docker pull rchain/rnode
Timing of Updates:
The test net will be updated after every release. Releases generally take place on Thursdays. Updates to the test net will take place on Monday mornings. The reason for this, is to ensure that the development team is available to support any possible issues that users may encounter after the update is deployed.
Updates would need to be co-ordinated with the validator set, including the deployment of the update on all the nodes, and then deployment of the genesis block. This will need to become part of the release deployment process. Kelly Foster - Note that we will Release on Thursday, then co-ordinate with Validators for a test net push on Monday. If data needs to be wiped, we will need to re-deploy the genesis block. If there is a network wipe, this is an opportunity for new validators to join the validator set if desired.
Data and State on the Test net:
The RChain platform is still very much under development. There are no guarantees on data stored on the test net. An update may require that the history on the network be wiped. If the network needs to be wiped, this will occur as part of the update. In this event, contract authors would need to re-deploy their contracts, and restart any tests that were in flight.
Addressing issues & Support:
dApp developers that encounter an issue or unexpected behavior while working with the test net should file a bug in Jira. ToDo: Create a component in Core for test net related issues and triage workflow.