Inclusivity changes for CloudStack - rename some offensive words/terms as appropriate, that are meaningful and inclusive.

- Renamed default git branch name from 'master' to 'main'.
- Removed black/whitelist phrasing, replaced with allowlist/denylist.
- Replaced some offensive words/terms with appropriate word for inclusiveness.

Author: sureshanaparti

README.rst

@@ -92,15 +92,15 @@ On your computer, follow these steps to setup a local repository for working on
    $ git clone https://github.com/YOUR_ACCOUNT/cloudstack-documentation.git
    $ cd cloudstack-docs-install
    $ git remote add upstream https://github.com/apache/cloudstack-documentation.git
-   $ git checkout master
+   $ git checkout main
    $ git fetch upstream
-   $ git merge upstream/master
+   $ git merge upstream/main
 
 
 Making changes
 --------------
 
-It is important that you create a new branch to make changes on and that you do not change the `master` branch (other than to pull in changes from `upstream/master`).  In this case I will assume you will be creating a branch called `dev` to make your changes in.  This `dev` branch will be created on your local repository and will then be pushed to your forked repository on GitHub where you will create a Pull Request for the changes to be committed into the official documentation.
+It is important that you create a new branch to make changes on and that you do not change the `main` branch (other than to pull in changes from `upstream/main`).  In this case I will assume you will be creating a branch called `dev` to make your changes in.  This `dev` branch will be created on your local repository and will then be pushed to your forked repository on GitHub where you will create a Pull Request for the changes to be committed into the official documentation.
 
 It is good practice to create a new branch each time you want to contribute to the documentation and only track the changes for that pull request in this branch.
 
@@ -115,40 +115,40 @@ It is good practice to create a new branch each time you want to contribute to t
    The `-b` specifies that you want to create a new branch called `dev`.  You only specify `-b` the first time because you are creating a new branch.  Once the `dev` branch exists, you can later switch to it with only `git checkout dev`.
 
 
-Merging `upstream/master` into your `dev` branch
+Merging `upstream/main` into your `dev` branch
 ------------------------------------------------
 
-It is important that you maintain an up-to-date `master` branch in your local repository.  This is done by merging in the `upstream/master` (the official documentation repository) into your local repository.  You will want to do this before you start working on a feature as well as right before you submit your changes as a pull request.  You can also do this process periodically while you work on your changes to make sure you are working off the most recent version of the documentation.
+It is important that you maintain an up-to-date `main` branch in your local repository.  This is done by merging in the `upstream/main` (the official documentation repository) into your local repository.  You will want to do this before you start working on a feature as well as right before you submit your changes as a pull request.  You can also do this process periodically while you work on your changes to make sure you are working off the most recent version of the documentation.
 
 This process will do the following:
 
-#. Checkout your local `master` branch
+#. Checkout your local `main` branch
 
-#. Synchronize your local `master` branch with the `upstream/master` so you have all the latest changes from the official docs
+#. Synchronize your local `main` branch with the `upstream/main` so you have all the latest changes from the official docs
 
 #. Merge the latest changes from the official docs into your `dev` branch so it is up-to-date with the latest changes
 
 .. code:: bash
 
-   $ git checkout master
+   $ git checkout main
    $ git fetch upstream
-   $ git merge upstream/master
+   $ git merge upstream/main
    $ git checkout dev
-   $ git pull . master
+   $ git pull . main
 
-.. note:: Now your `dev` branch is up-to-date with all the recent changes in the `upstream/master`.
+.. note:: Now your `dev` branch is up-to-date with all the recent changes in the `upstream/main`.
 
 
 Making a pull request on GitHub to contribute your changes
 ----------------------------------------------------------
 
 When you are happy with your changes and you want to contribute them, you will be creating a Pull Request on GitHub to do so.  This is done by pushing your changes to your forked repository (usually called 'origin') and then initiating a pull request.
 
-.. note:: Make sure you have merged `upstream/master` into your `dev` branch before you do this.
+.. note:: Make sure you have merged `upstream/main` into your `dev` branch before you do this.
 
 .. code:: bash
 
-   $ git push origin master
+   $ git push origin main
    $ git push origin dev
 
 Now that the `dev` branch has been pushed to your GitHub repository, you can initiate the pull request.  
@@ -167,14 +167,14 @@ If you are requested to make modifications to your proposed changes, make the ch
 Cleaning up after a successful pull request
 -------------------------------------------
 
-Once the `dev` branch has been committed into the `upstream/master` branch, your local `dev` branch and the `origin/dev` branch are not needed anymore.  If you want to make additional documentation changes, restart the process with a new branch.
+Once the `dev` branch has been committed into the `upstream/main` branch, your local `dev` branch and the `origin/dev` branch are not needed anymore.  If you want to make additional documentation changes, restart the process with a new branch.
 
-.. note:: Make sure that your changes are in `upstream/master` before you delete your `dev` and `origin/dev` branches!
+.. note:: Make sure that your changes are in `upstream/main` before you delete your `dev` and `origin/dev` branches!
 
 You can delete these deprecated branches with the following:
 
 .. code:: bash
 
-   $ git checkout master
+   $ git checkout main
    $ git branch -D dev
    $ git push origin :dev

source/adminguide/autoscale_without_netscaler.rst

@@ -18,7 +18,7 @@ Configuring AutoScale without using NetScaler
 =============================================
 
 .. warning:: 
-   This feature is currently only available on the master branch and will be 
+   This feature is currently only available on the main branch and will be 
    released in the 4.4 release.
 
 

source/adminguide/hosts.rst

@@ -76,8 +76,8 @@ XenServer and Maintenance Mode
 For XenServer, you can take a server offline temporarily by using the
 Maintenance Mode feature in XenCenter. When you place a server into
 Maintenance Mode, all running VMs are automatically migrated from it to
-another host in the same pool. If the server is the pool master, a new
-master will also be selected for the pool. While a server is Maintenance
+another host in the same pool. If the server is the pool primary, a new
+primary will also be selected for the pool. While a server is Maintenance
 Mode, you cannot create or start any VMs on it.
 
 **To place a server in Maintenance Mode:**

source/adminguide/index.rst

@@ -13,7 +13,7 @@
    specific language governing permissions and limitations
    under the License.
 
-.. CloudStack Administration Documentation master file, created by
+.. CloudStack Administration Documentation main file, created by
    sphinx-quickstart on Sat Jan 25 15:55:12 2014.
    You can adapt this file completely to your liking, but it should at least
    contain the root `toctree` directive.

source/adminguide/locale/pot/hosts.pot

@@ -103,7 +103,7 @@ msgstr ""
 
 #: ../../hosts.rst:80
 # 38555be75efd4fed91c3479a883493d1
-msgid "For XenServer, you can take a server offline temporarily by using the Maintenance Mode feature in XenCenter. When you place a server into Maintenance Mode, all running VMs are automatically migrated from it to another host in the same pool. If the server is the pool master, a new master will also be selected for the pool. While a server is Maintenance Mode, you cannot create or start any VMs on it."
+msgid "For XenServer, you can take a server offline temporarily by using the Maintenance Mode feature in XenCenter. When you place a server into Maintenance Mode, all running VMs are automatically migrated from it to another host in the same pool. If the server is the pool primary, a new primary will also be selected for the pool. While a server is Maintenance Mode, you cannot create or start any VMs on it."
 msgstr ""
 
 #: ../../hosts.rst:87

source/adminguide/locale/pot/networking.pot

@@ -730,7 +730,7 @@ msgstr ""
 
 #: ../../networking.rst:369
 # 6c9c68a68ab14d30a00460dd3b13f8a6
-msgid "**Redundant router capability**: Available only when Virtual Router is selected as the Source NAT provider. Select this option if you want to use two virtual routers in the network for uninterrupted connection: one operating as the master virtual router and the other as the backup. The master virtual router receives requests from and sends responses to the user’s VM. The backup virtual router is activated only when the master is down. After the failover, the backup becomes the master virtual router. CloudStack deploys the routers on different hosts to ensure reliability if one host is down."
+msgid "**Redundant router capability**: Available only when Virtual Router is selected as the Source NAT provider. Select this option if you want to use two virtual routers in the network for uninterrupted connection: one operating as the primary virtual router and the other as the backup. The primary virtual router receives requests from and sends responses to the user’s VM. The backup virtual router is activated only when the primary is down. After the failover, the backup becomes the primary virtual router. CloudStack deploys the routers on different hosts to ensure reliability if one host is down."
 msgstr ""
 
 #: ../../networking.rst:380

source/adminguide/locale/pot/networking/virtual_private_cloud_config.pot

@@ -1222,12 +1222,12 @@ msgstr ""
 
 #: ../../networking/virtual_private_cloud_config.rst:648
 # f66d2b908d63453ba9331658c3105974
-msgid "Blacklisting Routes"
+msgid "Denylisting Routes"
 msgstr ""
 
 #: ../../networking/virtual_private_cloud_config.rst:650
 # 5e262d8f57f94df080de1ebfd57089c5
-msgid "CloudStack enables you to block a list of routes so that they are not assigned to any of the VPC private gateways. Specify the list of routes that you want to blacklist in the ``blacklisted.routes`` global parameter. Note that the parameter update affects only new static route creations. If you block an existing static route, it remains intact and continue functioning. You cannot add a static route if the route is blacklisted for the zone."
+msgid "CloudStack enables you to block a list of routes so that they are not assigned to any of the VPC private gateways. Specify the list of routes that you want to denylist in the ``denied.routes`` global parameter. Note that the parameter update affects only new static route creations. If you block an existing static route, it remains intact and continue functioning. You cannot add a static route if the route is denied for the zone."
 msgstr ""
 
 #: ../../networking/virtual_private_cloud_config.rst:660

source/adminguide/locale/pot/networking2.pot

@@ -5988,12 +5988,12 @@ msgstr ""
 
 #: ../../networking2.rst:5737
 # 4bb61ba3dd1444269d2f517a3d774dac
-msgid "Blacklisting Routes"
+msgid "Denylisting Routes"
 msgstr ""
 
 #: ../../networking2.rst:5739
 # bf15aaf7395c48438bdfb1c5a1b303cd
-msgid "CloudStack enables you to block a list of routes so that they are not assigned to any of the VPC private gateways. Specify the list of routes that you want to blacklist in the ``blacklisted.routes`` global parameter. Note that the parameter update affects only new static route creations. If you block an existing static route, it remains intact and continue functioning. You cannot add a static route if the route is blacklisted for the zone."
+msgid "CloudStack enables you to block a list of routes so that they are not assigned to any of the VPC private gateways. Specify the list of routes that you want to denylist in the ``denied.routes`` global parameter. Note that the parameter update affects only new static route creations. If you block an existing static route, it remains intact and continue functioning. You cannot add a static route if the route is denied for the zone."
 msgstr ""
 
 #: ../../networking2.rst:5748

source/adminguide/locale/pot/networking_and_traffic.pot

@@ -5979,12 +5979,12 @@ msgstr ""
 
 #: ../../networking/virtual_private_cloud_config.rst:648
 # f5f80f387b5246caa603111d30dcfab7
-msgid "Blacklisting Routes"
+msgid "Denylisting Routes"
 msgstr ""
 
 #: ../../networking/virtual_private_cloud_config.rst:650
 # 8515025cd30a4b30b46f527ea9be5b2b
-msgid "CloudStack enables you to block a list of routes so that they are not assigned to any of the VPC private gateways. Specify the list of routes that you want to blacklist in the ``blacklisted.routes`` global parameter. Note that the parameter update affects only new static route creations. If you block an existing static route, it remains intact and continue functioning. You cannot add a static route if the route is blacklisted for the zone."
+msgid "CloudStack enables you to block a list of routes so that they are not assigned to any of the VPC private gateways. Specify the list of routes that you want to denylist in the ``denied.routes`` global parameter. Note that the parameter update affects only new static route creations. If you block an existing static route, it remains intact and continue functioning. You cannot add a static route if the route is denied for the zone."
 msgstr ""
 
 #: ../../networking/virtual_private_cloud_config.rst:660

source/adminguide/locale/pot/reliability.pot

@@ -283,22 +283,22 @@ msgstr ""
 
 #: ../../reliability.rst:207
 # 147ac9efb2314312b6e97323a267fd7c
-msgid "``db.cloud.slaves``: set to a comma-delimited set of slave hosts for the cloud database. This is the list of nodes set up with replication. The master node is not in the list, since it is already mentioned elsewhere in the properties file."
+msgid "``db.cloud.backup``: set to a comma-delimited set of backup hosts for the cloud database. This is the list of nodes set up with replication. The primary node is not in the list, since it is already mentioned elsewhere in the properties file."
 msgstr ""
 
 #: ../../reliability.rst:212
 # aa38f185ca8b4c1b86e19da970eb3901
-msgid "Example: ``db.cloud.slaves=node2,node3,node4``"
+msgid "Example: ``db.cloud.backup=node2,node3,node4``"
 msgstr ""
 
 #: ../../reliability.rst:214
 # 1783ef0808884e28ab22f6b3172dba41
-msgid "``db.usage.slaves``: set to a comma-delimited set of slave hosts for the usage database. This is the list of nodes set up with replication. The master node is not in the list, since it is already mentioned elsewhere in the properties file."
+msgid "``db.usage.backup``: set to a comma-delimited set of backup hosts for the usage database. This is the list of nodes set up with replication. The primary node is not in the list, since it is already mentioned elsewhere in the properties file."
 msgstr ""
 
 #: ../../reliability.rst:219
 # 573fb04445dd4b0ba4f5b9a5f8517c75
-msgid "Example: ``db.usage.slaves=node2,node3,node4``"
+msgid "Example: ``db.usage.backup=node2,node3,node4``"
 msgstr ""
 
 #: ../../reliability.rst:221
@@ -313,27 +313,27 @@ msgstr ""
 
 #: ../../reliability.rst:227
 # bcfa8dcb331c4185bab0cbdfbb3624ca
-msgid "``db.cloud.secondsBeforeRetryMaster``: The number of seconds the MySQL connector should wait before trying again to connect to the master after the master went down. Default is 1 hour. The retry might happen sooner if db.cloud.queriesBeforeRetryMaster is reached first."
+msgid "``db.cloud.secondsBeforeRetryPrimary``: The number of seconds the MySQL connector should wait before trying again to connect to the primary after the primary went down. Default is 1 hour. The retry might happen sooner if db.cloud.queriesBeforeRetryPrimary is reached first."
 msgstr ""
 
 #: ../../reliability.rst:232
 # 55d7217f8ea6408e8389bd39dbbfc3fc
-msgid "Example: ``db.cloud.secondsBeforeRetryMaster=3600``"
+msgid "Example: ``db.cloud.secondsBeforeRetryPrimary=3600``"
 msgstr ""
 
 #: ../../reliability.rst:234
 # d8cfb3b10706434d8ad7c63b231e7ee9
-msgid "``db.cloud.queriesBeforeRetryMaster``: The minimum number of queries to be sent to the database before trying again to connect to the master after the master went down. Default is 5000. The retry might happen sooner if db.cloud.secondsBeforeRetryMaster is reached first."
+msgid "``db.cloud.queriesBeforeRetryPrimary``: The minimum number of queries to be sent to the database before trying again to connect to the primary after the primary went down. Default is 5000. The retry might happen sooner if db.cloud.secondsBeforeRetryPrimary is reached first."
 msgstr ""
 
 #: ../../reliability.rst:239
 # f7b672a867c64854accef70177a0dd73
-msgid "Example: ``db.cloud.queriesBeforeRetryMaster=5000``"
+msgid "Example: ``db.cloud.queriesBeforeRetryPrimary=5000``"
 msgstr ""
 
 #: ../../reliability.rst:241
 # 2283aca3081443c585804a3c9d63a45d
-msgid "``db.cloud.initialTimeout``: Initial time the MySQL connector should wait before trying again to connect to the master. Default is 3600."
+msgid "``db.cloud.initialTimeout``: Initial time the MySQL connector should wait before trying again to connect to the primary. Default is 3600."
 msgstr ""
 
 #: ../../reliability.rst:244
@@ -353,7 +353,7 @@ msgstr ""
 
 #: ../../reliability.rst:253
 # 7c4a38ab45c943a489f2e7ae8f3ab0e2
-msgid "Slave hosts can not be monitored through CloudStack. You will need to have a separate means of monitoring."
+msgid "Backup hosts can not be monitored through CloudStack. You will need to have a separate means of monitoring."
 msgstr ""
 
 #: ../../reliability.rst:256