docs: moved 'Set Up and Run...' under 'Develop & Test BigchainDB' section

docs/source/clusters-feds/backup.md

@@ -22,7 +22,7 @@ That's just one possible way of setting up the file system so as to provide extr
 
 Another way to get similar reliability would be to mount the RethinkDB data directory on an [Amazon EBS](https://aws.amazon.com/ebs/) volume. Each Amazon EBS volume is, "automatically replicated within its Availability Zone to protect you from component failure, offering high availability and durability."
 
-See [the section on setting up storage for RethinkDB](../nodes/setup-run-node.html#set-up-storage-for-rethinkdb-data) for more details.
+See [the section on setting up storage for RethinkDB](../dev-and-test/setup-run-node.html#set-up-storage-for-rethinkdb-data) for more details.
 
 As with shard replication, live file-system replication protects against many failure modes, but it doesn't protect against them all. You should still consider having normal, "cold" backups.
 
@@ -108,7 +108,7 @@ Considerations for BigchainDB:
 
 Although it's not advertised as such, RethinkDB's built-in replication feature is similar to continous backup, except the "backup" (i.e. the set of replica shards) is spread across all the nodes. One could take that idea a bit farther by creating a set of backup-only servers with one full backup:
 
-* Give all the original BigchainDB nodes (RethinkDB nodes) the server tag `original`. This is the default if you used the RethinkDB config file suggested in the section titled [Configure RethinkDB Server](../nodes/setup-run-node.html#configure-rethinkdb-server).
+* Give all the original BigchainDB nodes (RethinkDB nodes) the server tag `original`. This is the default if you used the RethinkDB config file suggested in the section titled [Configure RethinkDB Server](../dev-and-test/setup-run-node.html#configure-rethinkdb-server).
 * Set up a group of servers running RethinkDB only, and give them the server tag `backup`. The `backup` servers could be geographically separated from all the `original` nodes (or not; it's up to the federation).
 * Clients shouldn't be able to read from or write to servers in the `backup` set.
 * Send a RethinkDB reconfigure command to the RethinkDB cluster to make it so that the `original` set has the same number of replicas as before (or maybe one less), and the `backup` set has one replica. Also, make sure the `primary_replica_tag='original'` so that all primary shards live on the `original` nodes.

docs/source/clusters-feds/monitoring.md

@@ -28,7 +28,7 @@ You can view the Grafana dashboard in your web browser at:
 
 (You may want to replace `localhost` with another hostname in that URL, e.g. the hostname of a remote monitoring server.)
 
-The login and password are `admin` by default. If BigchainDB is running and processing transactions, you should see analytics—if not, [start BigchainDB](../nodes/setup-run-node.html#run-bigchaindb) and load some test transactions:
+The login and password are `admin` by default. If BigchainDB is running and processing transactions, you should see analytics—if not, [start BigchainDB](../dev-and-test/setup-run-node.html#run-bigchaindb) and load some test transactions:
 ```text
 $ bigchaindb load
 ```

docs/source/clusters-feds/set-up-a-federation.md

@@ -20,7 +20,7 @@ The federation must decide some things before setting up the initial cluster (in
 3. Which node will be responsible for sending the commands to configure the RethinkDB database?
 
 Once those things have been decided, each node operator can begin setting up their BigchainDB node.
-The steps to set up a cluster node are outlined in the section titled [Set Up and Run a Node](../nodes/setup-run-node.html). Each node operator will eventually need two pieces of information from all other nodes in the federation:
+The steps to set up a cluster node are outlined in the section titled [Set Up and Run a Node](../dev-and-test/setup-run-node.html). Each node operator will eventually need two pieces of information from all other nodes in the federation:
 
 1. Their RethinkDB hostname, e.g. `rdb.farm2.organization.org`
 2. Their BigchainDB public key, e.g. `Eky3nkbxDTMgkmiJC8i5hKyVFiAQNmPP4a2G4JdDxJCK`

docs/source/dev-and-test/index.rst

@@ -7,4 +7,5 @@ Develop & Test BigchainDB
 .. toctree::
    :maxdepth: 1
 
+   setup-run-node
    running-unit-tests

docs/source/drivers-clients/python-server-api-examples.md

@@ -9,7 +9,7 @@ One can also interact with a BigchainDB node via other APIs, including the HTTP
 
 ## Getting Started
 
-First, make sure you have RethinkDB and BigchainDB _installed and running_, i.e. you [installed them](setup-run-node.html) and you ran:
+First, make sure you have RethinkDB and BigchainDB _installed and running_, i.e. you [installed them](../dev-and-test/setup-run-node.html) and you ran:
 ```text
 $ rethinkdb
 $ bigchaindb configure

docs/source/nodes/index.rst

@@ -9,5 +9,4 @@ BigchainDB Nodes
 
    node-components
    node-requirements
-   setup-run-node
    run-with-docker