Problem: Docs say "BigchainDB cluster" but IRL we say "BigchainDB network" (#2471)

Solution: Edit the docs to say "BigchainDB network" instead

docs/root/source/assets.rst

@@ -8,7 +8,7 @@ How BigchainDB is Good for Asset Registrations & Transfers
 
 BigchainDB can store data of any kind (within reason), but it's designed to be particularly good for storing asset registrations and transfers:
 
-* The fundamental thing that one sends to a BigchainDB cluster, to be checked and stored (if valid), is a *transaction*, and there are two kinds: CREATE transactions and TRANSFER transactions.
+* The fundamental thing that one sends to a BigchainDB network, to be checked and stored (if valid), is a *transaction*, and there are two kinds: CREATE transactions and TRANSFER transactions.
 * A CREATE transaction can be use to register any kind of asset (divisible or indivisible), along with arbitrary metadata.
 * An asset can have zero, one, or several owners.
 * The owners of an asset can specify (crypto-)conditions which must be satisfied by anyone wishing transfer the asset to new owners. For example, a condition might be that at least 3 of the 5 current owners must cryptographically sign a TRANSFER transaction.

docs/root/source/decentralized.md

@@ -8,9 +8,9 @@ Code is Apache-2.0 and docs are CC-BY-4.0
 
 Decentralization means that no one owns or controls everything, and there is no single point of failure.
 
-Ideally, each node in a BigchainDB cluster is owned and controlled by a different person or organization. Even if the cluster lives within one organization, it's still preferable to have each node controlled by a different person or subdivision.
+Ideally, each node in a BigchainDB network is owned and controlled by a different person or organization. Even if the network lives within one organization, it's still preferable to have each node controlled by a different person or subdivision.
 
-We use the phrase "BigchainDB consortium" (or just "consortium") to refer to the set of people and/or organizations who run the nodes of a BigchainDB cluster. A consortium requires some form of governance to make decisions such as membership and policies. The exact details of the governance process are determined by each consortium, but it can be very decentralized.
+We use the phrase "BigchainDB consortium" (or just "consortium") to refer to the set of people and/or organizations who run the nodes of a BigchainDB network. A consortium requires some form of governance to make decisions such as membership and policies. The exact details of the governance process are determined by each consortium, but it can be very decentralized.
 
 If sharding is turned on (i.e. if the number of shards is larger than one), then the actual data is decentralized in that no one node stores all the data.
 
@@ -18,8 +18,8 @@ Every node has its own locally-stored list of the public keys of other consortiu
 
 A consortium can increase its decentralization (and its resilience) by increasing its jurisdictional diversity, geographic diversity, and other kinds of diversity. This idea is expanded upon in [the section on node diversity](diversity.html).
 
-There’s no node that has a long-term special position in the cluster. All nodes run the same software and perform the same duties.
+There’s no node that has a long-term special position in the BigchainDB network. All nodes run the same software and perform the same duties.
 
-If someone has (or gets) admin access to a node, they can mess with that node (e.g. change or delete data stored on that node), but those changes should remain isolated to that node. The BigchainDB cluster can only be compromised if more than one third of the nodes get compromised. See the [Tendermint documentation](https://tendermint.readthedocs.io/projects/tools/en/master/introduction.html) for more details.
+If someone has (or gets) admin access to a node, they can mess with that node (e.g. change or delete data stored on that node), but those changes should remain isolated to that node. The BigchainDB network can only be compromised if more than one third of the nodes get compromised. See the [Tendermint documentation](https://tendermint.readthedocs.io/projects/tools/en/master/introduction.html) for more details.
 
 It’s worth noting that not even the admin or superuser of a node can transfer assets. The only way to create a valid transfer transaction is to fulfill the current crypto-conditions on the asset, and the admin/superuser can’t do that because the admin user doesn’t have the necessary information (e.g. private keys).

docs/root/source/index.rst

@@ -13,7 +13,7 @@ including `decentralization <decentralized.html>`_,
 `immutability <immutable.html>`_ 
 and `native support for assets <assets.html>`_.
 
-At a high level, one can communicate with a BigchainDB cluster (set of nodes) using the BigchainDB HTTP API, or a wrapper for that API, such as the BigchainDB Python Driver. Each BigchainDB node runs BigchainDB Server and various other software. The `terminology page <terminology.html>`_ explains some of those terms in more detail.
+At a high level, one can communicate with a BigchainDB network (set of nodes) using the BigchainDB HTTP API, or a wrapper for that API, such as the BigchainDB Python Driver. Each BigchainDB node runs BigchainDB Server and various other software. The `terminology page <terminology.html>`_ explains some of those terms in more detail.
 
 .. raw:: html
 

docs/root/source/terminology.md

@@ -12,14 +12,14 @@ There is some specialized terminology associated with BigchainDB. To get started
 
 A **BigchainDB node** is a machine (or logical machine) running [BigchainDB Server](https://docs.bigchaindb.com/projects/server/en/latest/introduction.html) and related software. Each node is controlled by one person or organization.
 
-## BigchainDB Cluster
+## BigchainDB Network
 
-A set of BigchainDB nodes can connect to each other to form a **BigchainDB cluster**. Each node in the cluster runs the same software. A cluster may have additional machines to do things such as cluster monitoring.
+A set of BigchainDB nodes can connect to each other to form a **BigchainDB network**. Each node in the network runs the same software. A BigchainDB network may have additional machines to do things such as  monitoring.
 
 ## BigchainDB Consortium
 
-The people and organizations that run the nodes in a cluster belong to a **BigchainDB consortium** (i.e. another organization). A consortium must have some sort of governance structure to make decisions. If a cluster is run by a single company, then the "consortium" is just that company.
+The people and organizations that run the nodes in a BigchainDB network belong to a **BigchainDB consortium** (i.e. another organization). A consortium must have some sort of governance structure to make decisions. If a BigchainDB network is run by a single company, then the "consortium" is just that company.
 
-**What's the Difference Between a Cluster and a Consortium?**
+**What's the Difference Between a BigchainDB Network and a Consortium?**
 
-A cluster is just a bunch of connected nodes. A consortium is an organization which has a cluster, and where each node in the cluster has a different operator.
+A BigchaindB network is just a bunch of connected nodes. A consortium is an organization which has a BigchainDB network, and where each node in that network has a different operator.

docs/server/source/appendices/aws-setup.md

@@ -4,36 +4,36 @@ SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0)
 Code is Apache-2.0 and docs are CC-BY-4.0
 --->
 
-# Basic AWS Setup 
+# Basic AWS Setup
 
 Before you can deploy anything on AWS, you must do a few things.
 
-
 ## Get an AWS Account
 
 If you don't already have an AWS account, you can [sign up for one for free at aws.amazon.com](https://aws.amazon.com/).
 
-
 ## Install the AWS Command-Line Interface
 
 To install the AWS Command-Line Interface (CLI), just do:
+
 ```text
 pip install awscli
 ```
 
-
 ## Create an AWS Access Key
 
 The next thing you'll need is AWS access keys (access key ID and secret access key). If you don't have those, see [the AWS documentation about access keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys).
 
-You should also pick a default AWS region name (e.g. `eu-central-1`). That's where your cluster will run. The AWS documentation has [a list of them](http://docs.aws.amazon.com/general/latest/gr/rande.html#ec2_region).
+You should also pick a default AWS region name (e.g. `eu-central-1`). The AWS documentation has [a list of them](http://docs.aws.amazon.com/general/latest/gr/rande.html#ec2_region).
 
 Once you've got your AWS access key, and you've picked a default AWS region name, go to a terminal session and enter:
+
 ```text
 aws configure
 ```
 
 and answer the four questions. For example:
+
 ```text
 AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
 AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
@@ -43,17 +43,16 @@ Default output format [None]: [Press Enter]
 
 This writes two files: `~/.aws/credentials` and `~/.aws/config`. AWS tools and packages look for those files.
 
-
 ## Generate an RSA Key Pair for SSH
 
 Eventually, you'll have one or more instances (virtual machines) running on AWS and you'll want to SSH to them. To do that, you need a public/private key pair. The public key will be sent to AWS, and you can tell AWS to put it in any instances you provision there. You'll keep the private key on your local workstation.
 
 See the [page about how to generate a key pair for SSH](generate-key-pair-for-ssh.html).
 
-
 ## Send the Public Key to AWS
 
 To send the public key to AWS, use the AWS Command-Line Interface:
+
 ```text
 aws ec2 import-key-pair \
 --key-name "<key-name>" \

docs/server/source/index.rst

@@ -14,7 +14,7 @@ BigchainDB Server Documentation
    quickstart
    network-operations/index
    production-nodes/index
-   clusters
+   networks
    dev-and-test/index
    server-reference/index
    http-client-server-api

docs/server/source/introduction.md

@@ -14,17 +14,15 @@ Note that there are a few kinds of nodes:
 
 - A **dev/test node** is a node created by a developer working on BigchainDB Server, e.g. for testing new or changed code. A dev/test node is typically run on the developer's local machine.
 
-- A **bare-bones node** is a node deployed in the cloud, either as part of a testing cluster or as a starting point before upgrading the node to be production-ready.
-
-- A **production node** is a node that is part of a consortium's BigchainDB cluster. A production node has the most components and requirements.
+- A **bare-bones node** is a node deployed in the cloud, either as part of a testing network or as a starting point before upgrading the node to be production-ready.
 
+- A **production node** is a node that is part of a consortium's BigchainDB network. A production node has the most components and requirements.
 
 ## Setup Instructions for Various Cases
 
-* [Quickstart](quickstart.html)
-* [Set up a local BigchainDB node for development, experimenting and testing](https://docs.bigchaindb.com/projects/contributing/en/latest/dev-setup-coding-and-contribution-process/index.html)
-* [Set up and run a BigchainDB cluster](clusters.html)
-
+- [Quickstart](quickstart.html)
+- [Set up a local BigchainDB node for development, experimenting and testing](https://docs.bigchaindb.com/projects/contributing/en/latest/dev-setup-coding-and-contribution-process/index.html)
+- [Set up and run a BigchainDB network](network-operations/index.html)
 
 ## Can I Help?
 

docs/server/source/k8s-deployment-template/ca-installation.rst

@@ -9,8 +9,8 @@ How to Set Up a Self-Signed Certificate Authority
 =================================================
 
 This page enumerates the steps *we* use to set up a self-signed certificate authority (CA).
-This is something that only needs to be done once per cluster,
-by the organization managing the cluster, i.e. the CA is for the whole cluster.
+This is something that only needs to be done once per BigchainDB network,
+by the organization managing the network, i.e. the CA is for the whole network.
 We use Easy-RSA.
 
 

docs/server/source/k8s-deployment-template/client-tls-certificate.rst

@@ -9,7 +9,7 @@ How to Generate a Client Certificate for MongoDB
 ================================================
 
 This page enumerates the steps *we* use to generate a client certificate to be
-used by clients who want to connect to a TLS-secured MongoDB cluster.
+used by clients who want to connect to a TLS-secured MongoDB database.
 We use Easy-RSA.
 
 
@@ -42,7 +42,7 @@ and using:
 
 You should change the Common Name (e.g. ``bdb-instance-0``)
 to a value that reflects what the
-client certificate is being used for, e.g. ``mdb-mon-instance-3`` or ``mdb-bak-instance-4``. (The final integer is specific to your BigchainDB node in the BigchainDB cluster.)
+client certificate is being used for, e.g. ``mdb-mon-instance-3`` or ``mdb-bak-instance-4``. (The final integer is specific to your BigchainDB node in the BigchainDB network.)
 
 You will be prompted to enter the Distinguished Name (DN) information for this certificate. For each field, you can accept the default value [in brackets] by pressing Enter.
 
@@ -66,7 +66,7 @@ Step 3: Get the Client Certificate Signed
 The CSR file created in the previous step
 should be located in ``pki/reqs/bdb-instance-0.req``
 (or whatever Common Name you used in the ``gen-req`` command above).
-You need to send it to the organization managing the cluster
+You need to send it to the organization managing the BigchainDB network
 so that they can use their CA
 to sign the request.
 (The managing organization should already have a self-signed CA.)

docs/server/source/k8s-deployment-template/index.rst

@@ -17,7 +17,7 @@ Kubernetes Deployment Template
    and your organization has people who know Kubernetes,
    then this Kubernetes deployment template might be helpful.
 
-This section outlines a way to deploy a BigchainDB node (or BigchainDB cluster)
+This section outlines a way to deploy a BigchainDB node (or BigchainDB network)
 on Microsoft Azure using Kubernetes.
 You may choose to use it as a template or reference for your own deployment,
 but *we make no claim that it is suitable for your purposes*.

docs/server/source/k8s-deployment-template/log-analytics.rst

@@ -170,7 +170,7 @@ Until we figure out a way to obtain the *workspace key* via the command line,
 you can get it via the OMS Portal.
 To get to the OMS Portal, go to the Azure Portal and click on:
 
-Resource Groups > (Your k8s cluster's resource group) > Log analytics (OMS) > (Name of the only item listed) > OMS Workspace > OMS Portal
+Resource Groups > (Your Kubernetes cluster's resource group) > Log analytics (OMS) > (Name of the only item listed) > OMS Workspace > OMS Portal
 
 (Let us know if you find a faster way.)
 Then see `Microsoft's instructions to obtain your workspace ID and key

docs/server/source/k8s-deployment-template/node-config-map-and-secrets.rst

@@ -74,7 +74,7 @@ This user is created on the *admin* database with the authorization to create ot
 
 vars.BDB_PERSISTENT_PEERS, BDB_VALIDATORS, BDB_VALIDATORS_POWERS, BDB_GENESIS_TIME and BDB_CHAIN_ID
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-These parameters are shared across the cluster. More information about the generation
+These parameters are shared across the BigchainDB network. More information about the generation
 of these parameters can be found at :ref:`generate-the-blockchain-id-and-genesis-time`.
 
 
@@ -82,7 +82,7 @@ vars.NODE_DNS_SERVER
 ^^^^^^^^^^^^^^^^^^^^
 IP of Kubernetes service(kube-dns), can be retrieved using
 using CLI(kubectl) or k8s dashboard. This parameter is used by the Nginx gateway instance
-to resolve the hostnames of all the services running in the k8s cluster.
+to resolve the hostnames of all the services running in the Kubernetes cluster.
 
 .. code::
 

docs/server/source/k8s-deployment-template/revoke-tls-certificate.rst

@@ -7,9 +7,9 @@ How to Revoke an SSL/TLS Certificate
 ====================================
 
 This page enumerates the steps *we* take to revoke a self-signed SSL/TLS
-certificate in a cluster.
+certificate in a BigchainDB network.
 It can only be done by someone with access to the self-signed CA
-associated with the cluster's managing organization.
+associated with the network's managing organization.
 
 Step 1: Revoke a Certificate
 ----------------------------
@@ -45,4 +45,4 @@ Generate a new CRL for your infrastructure using:
 The generated ``crl.pem`` file needs to be uploaded to your infrastructure to
 prevent the revoked certificate from being used again.
 
-In particlar, the generated ``crl.pem`` file should be sent to all BigchainDB node operators in your BigchainDB cluster, so that they can update it in their MongoDB instance and their BigchainDB Server instance.
+In particlar, the generated ``crl.pem`` file should be sent to all BigchainDB node operators in your BigchainDB network, so that they can update it in their MongoDB instance and their BigchainDB Server instance.

docs/server/source/k8s-deployment-template/server-tls-certificate.rst

@@ -47,7 +47,7 @@ and using something like:
 
    ./easyrsa --req-cn=mdb-instance-0 --subject-alt-name=DNS:localhost,DNS:mdb-instance-0 gen-req mdb-instance-0 nopass
 
-You should replace the Common Name (``mdb-instance-0`` above) with the correct name for *your* MongoDB instance in the cluster, e.g. ``mdb-instance-5`` or ``mdb-instance-12``. (This name is decided by the organization managing the cluster.)
+You should replace the Common Name (``mdb-instance-0`` above) with the correct name for *your* MongoDB instance in the network, e.g. ``mdb-instance-5`` or ``mdb-instance-12``. (This name is decided by the organization managing the network.)
 
 You will be prompted to enter the Distinguished Name (DN) information for this certificate.
 For each field, you can accept the default value [in brackets] by pressing Enter.
@@ -68,7 +68,7 @@ Step 3: Get the Server Certificate Signed
 The CSR file created in the last step
 should be located in ``pki/reqs/mdb-instance-0.req``
 (where the integer ``0`` may be different for you).
-You need to send it to the organization managing the cluster
+You need to send it to the organization managing the BigchainDB network
 so that they can use their CA
 to sign the request.
 (The managing organization should already have a self-signed CA.)

docs/server/source/k8s-deployment-template/workflow.rst

@@ -20,7 +20,7 @@ Overview
    then this Kubernetes deployment template might be helpful.
 
 This page summarizes some steps to go through
-to set up a BigchainDB cluster.
+to set up a BigchainDB network.
 You can modify them to suit your needs.
 
 .. _generate-the-blockchain-id-and-genesis-time:
@@ -30,7 +30,7 @@ Generate All Shared BigchainDB Setup Parameters
 
 There are some shared BigchainDB setup paramters that every node operator
 in the consortium shares
-because they are properties of the Tendermint cluster.
+because they are properties of the Tendermint network.
 They look like this:
 
 .. code::
@@ -46,7 +46,7 @@ Those paramters only have to be generated once, by one member of the consortium.
 That person will then share the results (Tendermint setup parameters)
 with all the node operators.
 
-The above example parameters are for a cluster of 4 initial (seed) nodes.
+The above example parameters are for a network of 4 initial (seed) nodes.
 Note how ``BDB_PERSISTENT_PEERS``, ``BDB_VALIDATORS`` and ``BDB_VALIDATOR_POWERS`` are lists
 with 4 items each.
 **If your consortium has a different number of initial nodes,
@@ -119,7 +119,7 @@ to all POST requests with a secret token in the HTTP headers.
 You can make up that ``SECRET_TOKEN`` now.
 For example, ``superSECRET_token4-POST*requests``.
 You will put it in the ``vars`` file later.
-Every BigchainDB node in a cluster can have a different secret token.
+Every BigchainDB node in a BigchainDB network can have a different secret token.
 To make an HTTP POST request to your BigchainDB node,
 you must include an HTTP header named ``X-Secret-Access-Token``
 and set it equal to your secret token, e.g.
@@ -136,7 +136,7 @@ and set it equal to your secret token, e.g.
    between different Kubernetes clusters, especially if they are running different versions of Kubernetes.
    We tested this Kubernetes Deployment Template on Azure ACS in February 2018 and at that time
    ACS was deploying a **Kubernetes 1.7.7** cluster. If you can force your cluster to have that version of Kubernetes,
-   then you'll increase the likelihood that everything will work in your cluster.
+   then you'll increase the likelihood that everything will work.
 
 4. Deploy your BigchainDB node inside your new Kubernetes cluster.
 You will fill up the ``vars`` file,

docs/server/source/networks.md

@@ -4,9 +4,9 @@ SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0)
 Code is Apache-2.0 and docs are CC-BY-4.0
 --->
 
-# Clusters
+# BigchainDB Networks
 
-A **BigchainDB Cluster** is a set of connected **BigchainDB Nodes**, managed by a **BigchainDB Consortium** (i.e. an organization). Those terms are defined in the [BigchainDB Terminology page](https://docs.bigchaindb.com/en/latest/terminology.html).
+A **BigchainDB network** is a set of connected **BigchainDB nodes**, managed by a **BigchainDB consortium** (i.e. an organization). Those terms are defined in the [BigchainDB Terminology page](https://docs.bigchaindb.com/en/latest/terminology.html).
 
 ## Consortium Structure & Governance
 
@@ -15,18 +15,18 @@ It must make many decisions, e.g. How will new members be added? Who can read th
 A governance process is required to make those decisions, and therefore one of the first steps for any new consortium is to specify its governance process (if one doesn't already exist).
 This documentation doesn't explain how to create a consortium, nor does it outline the possible governance processes.
 
-It's worth noting that the decentralization of a BigchainDB cluster depends,
+It's worth noting that the decentralization of a BigchainDB network depends,
 to some extent, on the decentralization of the associated consortium. See the pages about [decentralization](https://docs.bigchaindb.com/en/latest/decentralized.html) and [node diversity](https://docs.bigchaindb.com/en/latest/diversity.html).
 
-## Cluster DNS Records and SSL Certificates
+## DNS Records and SSL Certificates
 
-We now describe how *we* set up the external (public-facing) DNS records for a BigchainDB cluster. Your consortium may opt to do it differently.
+We now describe how *we* set up the external (public-facing) DNS records for a BigchainDB network. Your consortium may opt to do it differently.
 There were several goals:
 
-* Allow external users/clients to connect directly to any BigchainDB node in the cluster (over the internet), if they want.
+* Allow external users/clients to connect directly to any BigchainDB node in the network (over the internet), if they want.
 * Each BigchainDB node operator should get an SSL certificate for their BigchainDB node, so that their BigchainDB node can serve the [BigchainDB HTTP API](http-client-server-api.html) via HTTPS. (The same certificate might also be used to serve the [WebSocket API](websocket-event-stream-api.html).)
 * There should be no sharing of SSL certificates among BigchainDB node operators.
-* Optional: Allow clients to connect to a "random" BigchainDB node in the cluster at one particular domain (or subdomain).
+* Optional: Allow clients to connect to a "random" BigchainDB node in the network at one particular domain (or subdomain).
 
 ### Node Operator Responsibilities
 
@@ -36,8 +36,8 @@ There were several goals:
 
 ### Consortium Responsibilities
 
-Optional: The consortium managing the BigchainDB cluster could register a domain name and set up CNAME records mapping that domain name (or one of its subdomains) to each of the nodes in the cluster. For example, if the consortium registered `bdbcluster.io`, they could set up CNAME records like the following:
+Optional: The consortium managing the BigchainDB network could register a domain name and set up CNAME records mapping that domain name (or one of its subdomains) to each of the nodes in the network. For example, if the consortium registered `bdbnetwork.io`, they could set up CNAME records like the following:
 
-* CNAME record mapping `api.bdbcluster.io` to `abc-org73.net`
-* CNAME record mapping `api.bdbcluster.io` to `api.dynabob8.io`
-* CNAME record mapping `api.bdbcluster.io` to `figmentdb3.ninja`
+* CNAME record mapping `api.bdbnetwork.io` to `abc-org73.net`
+* CNAME record mapping `api.bdbnetwork.io` to `api.dynabob8.io`
+* CNAME record mapping `api.bdbnetwork.io` to `figmentdb3.ninja`

docs/server/source/production-nodes/node-assumptions.md

@@ -8,11 +8,10 @@ Code is Apache-2.0 and docs are CC-BY-4.0
 
 Be sure you know the key BigchainDB terminology:
 
-* [BigchainDB node, BigchainDB cluster and BigchainDB consortium](https://docs.bigchaindb.com/en/latest/terminology.html)
+* [BigchainDB node, BigchainDB network and BigchainDB consortium](https://docs.bigchaindb.com/en/latest/terminology.html)
 * [dev/test node, bare-bones node and production node](../introduction.html)
 
 We make some assumptions about production nodes:
 
-1. Production nodes use MongoDB (not RethinkDB, PostgreSQL, Couchbase or whatever).
 1. Each production node is set up and managed by an experienced professional system administrator or a team of them.
-1. Each production node in a cluster is managed by a different person or team.
+1. Each production node in a network is managed by a different person or team.

docs/server/source/production-nodes/node-components.md

@@ -17,7 +17,7 @@ It could also include several other components, including:
 
 * NGINX or similar, to provide authentication, rate limiting, etc.
 * An NTP daemon running on all machines running BigchainDB Server or mongod, and possibly other machines
-* **Not** MongoDB Automation Agent. It's for automating the deployment of an entire MongoDB cluster, not just one MongoDB node within a cluster.
+* Probably _not_ MongoDB Automation Agent. It's for automating the deployment of an entire MongoDB cluster.
 * MongoDB Monitoring Agent
 * MongoDB Backup Agent
 * Log aggregation software