Inclusivity changes for CloudStack in the documentation - Rename default git branch name from 'master' to 'main' and replace some offensive words/terms as appropriate (#155)

* Renamed default git branch name from 'master' to 'main', for inclusiveness.

* Updated master and slave(s) in the database context, with source and replica(s) respectively for inclusiveness.

* Updated the configurations 'user.vm.blacklisted.details' and 'blacklisted.routes', to 'user.vm.denied.details' and 'denied.routes' respectively and other related offending words for inclusiveness.

* Updated redundant state of router from 'master' to 'primary', to be more inclusive.

* Updated whitelist, blacklist, master, slave and some other offensive words/terms as appropriate for inclusiveness.

* Updated kubernetes service docs with inclusive words/terms.

* Update some doc with gender-inclusive words

* Reverted Sphinx conf changes

Co-authored-by: Suresh Kumar Anaparti <suresh.anaparti@shapeblue.com>
Co-authored-by: sureshanaparti <12028987+sureshanaparti@users.noreply.github.com>

Author: DaanHoogland

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

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

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/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.replicas``: set to a comma-delimited set of replica hosts for the cloud database. This is the list of nodes set up with replication. The source 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.replicas=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.replicas``: set to a comma-delimited set of replica hosts for the usage database. This is the list of nodes set up with replication. The source 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.replicas=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.secondsBeforeRetrySource``: The number of seconds the MySQL connector should wait before trying again to connect to the source after the source went down. Default is 1 hour. The retry might happen sooner if db.cloud.queriesBeforeRetrySource is reached first."
 msgstr ""
 
 #: ../../reliability.rst:232
 # 55d7217f8ea6408e8389bd39dbbfc3fc
-msgid "Example: ``db.cloud.secondsBeforeRetryMaster=3600``"
+msgid "Example: ``db.cloud.secondsBeforeRetrySource=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.queriesBeforeRetrySource``: The minimum number of queries to be sent to the database before trying again to connect to the source after the source went down. Default is 5000. The retry might happen sooner if db.cloud.secondsBeforeRetrySource is reached first."
 msgstr ""
 
 #: ../../reliability.rst:239
 # f7b672a867c64854accef70177a0dd73
-msgid "Example: ``db.cloud.queriesBeforeRetryMaster=5000``"
+msgid "Example: ``db.cloud.queriesBeforeRetrySource=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 source. 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 "Replica hosts can not be monitored through CloudStack. You will need to have a separate means of monitoring."
 msgstr ""
 
 #: ../../reliability.rst:256

source/adminguide/locale/pot/templates.pot

@@ -341,7 +341,7 @@ msgstr ""
 
 #: ../../templates.rst:288
 # 942a09f060a248499ad52006fb12910b
-msgid "Linux templates should be prepared using this documentation in order to prepare your linux VMs for template deployment. For ease of documentation, the VM which you are configuring the template on will be referred to as \"Template Master\". This guide currently covers legacy setups which do not take advantage of UserData and cloud-init and assumes openssh-server is installed during installation."
+msgid "Linux templates should be prepared using this documentation in order to prepare your linux VMs for template deployment. For ease of documentation, the VM which you are configuring the template on will be referred to as \"Template Primary\". This guide currently covers legacy setups which do not take advantage of UserData and cloud-init and assumes openssh-server is installed during installation."
 msgstr ""
 
 #: ../../templates.rst:295
@@ -417,7 +417,7 @@ msgstr ""
 
 #: ../../templates.rst:341
 # f68b6e4efb764f92a1e56ad9ea54f90c
-msgid "The next steps updates the packages on the Template Master."
+msgid "The next steps updates the packages on the Template Primary."
 msgstr ""
 
 #: ../../templates.rst:343
@@ -473,7 +473,7 @@ msgstr ""
 
 #: ../../templates.rst:434
 # 1f68693847f1433bb6541b70f1abedd5
-msgid "The following steps should be run when you are ready to template your Template Master. If the Template Master is rebooted during these steps you will have to run all the steps again. At the end of this process the Template Master should be shutdown and the template created in order to create and deploy the final template."
+msgid "The following steps should be run when you are ready to template your Template Primary. If the Template Primary is rebooted during these steps you will have to run all the steps again. At the end of this process the Template Primary should be shutdown and the template created in order to create and deploy the final template."
 msgstr ""
 
 #: ../../templates.rst:440
@@ -483,7 +483,7 @@ msgstr ""
 
 #: ../../templates.rst:442
 # 7a1b5554792c4cb1aa676f8e73a843b8
-msgid "This step removes information unique to your Template Master such as network MAC addresses, lease files and CD block devices, the files are automatically generated on next boot."
+msgid "This step removes information unique to your Template Primary such as network MAC addresses, lease files and CD block devices, the files are automatically generated on next boot."
 msgstr ""
 
 #: ../../templates.rst:460
@@ -503,7 +503,7 @@ msgstr ""
 
 #: ../../templates.rst:472
 # af913fb8f91b484bb83ac0737e1b1d10
-msgid "It is good practice to remove old logs from the Template Master."
+msgid "It is good practice to remove old logs from the Template Primary."
 msgstr ""
 
 #: ../../templates.rst:481
@@ -513,7 +513,7 @@ msgstr ""
 
 #: ../../templates.rst:483
 # 5a2162138fca40088196712b5650f551
-msgid "In order for the Ubuntu DHCP script to function and the CentOS dhclient to set the VM hostname they both require the Template Master's hostname to be \"localhost\", run the following commands to change the hostname."
+msgid "In order for the Ubuntu DHCP script to function and the CentOS dhclient to set the VM hostname they both require the Template Primary's hostname to be \"localhost\", run the following commands to change the hostname."
 msgstr ""
 
 #: ../../templates.rst:493
@@ -543,7 +543,7 @@ msgstr ""
 
 #: ../../templates.rst:513
 # f92b1a930b3e4d859616309b9db518e1
-msgid "Your now ready to shutdown your Template Master and create a template!"
+msgid "Your now ready to shutdown your Template Primary and create a template!"
 msgstr ""
 
 #: ../../templates.rst:520