Consistent use of single vs double quotes (#330)

* Consistent use of single vs double quotes

* Fix doc build errors

docs/architecture.rst

@@ -54,10 +54,10 @@ Blueprints
 Blueprint CRs are a set of instructions that tell the controller how to perform
 actions on a specific application.
 
-A Blueprint contains a field called `Actions` which is a mapping of Action Name
-to `BlueprintAction`.
+A Blueprint contains a field called ``Actions`` which is a mapping of Action Name
+to ``BlueprintAction``.
 
-The definition of a `BlueprintAction` is:
+The definition of a ``BlueprintAction`` is:
 
 .. code-block:: go
   :linenos:
@@ -73,16 +73,16 @@ The definition of a `BlueprintAction` is:
       Phases             []BlueprintPhase    `json:"phases"`
   }
 
-- `Kind` represents the type of Kubernetes object this BlueprintAction is written for.
+- ``Kind`` represents the type of Kubernetes object this BlueprintAction is written for.
   Specifying this is optional and going forward, if this is specified, Kanister will
-  enforce that it matches the `Object` kind specified in an ActionSet referencing this
+  enforce that it matches the ``Object`` kind specified in an ActionSet referencing this
   BlueprintAction
-- `ConfigMapNames`, `SecretNames`, `InputArtifactNames` are optional
+- ``ConfigMapNames``, ``SecretNames``, ``InputArtifactNames`` are optional
   but, if specified, they list named parameters that must be included by
-  the `ActionSet`.
-- `OutputArtifacts` is an optional map of rendered parameters made available
-  to the `BlueprintAction`.
-- `Phases` is a required list of `BlueprintPhases`. These phases are invoked
+  the ``ActionSet``.
+- ``OutputArtifacts`` is an optional map of rendered parameters made available
+  to the ``BlueprintAction``.
+- ``Phases`` is a required list of ``BlueprintPhases``. These phases are invoked
   in order when executing this Action.
 
 .. code-block:: go
@@ -96,13 +96,13 @@ The definition of a `BlueprintAction` is:
       Args       map[string]interface{}     `json:"args"`
   }
 
-- `Func` is required as the name of a registered Kanister function.
+- ``Func`` is required as the name of a registered Kanister function.
   See :ref:`functions` for the list of  functions supported by the controller.
-- `Name` is mostly cosmetic. It is useful in quickly identifying which
+- ``Name`` is mostly cosmetic. It is useful in quickly identifying which
   phases the controller has finished executing.
-- `Object` is a map of references to the Kubernetes objects on which
+- ``Object`` is a map of references to the Kubernetes objects on which
   the action will be performed.
-- `Args` is a map of named arguments that the controller will pass to
+- ``Args`` is a map of named arguments that the controller will pass to
   the Kanister function.
   String argument values can be templates that the controller will
   render using the template parameters. Each argument is rendered
@@ -155,19 +155,19 @@ as follows:
       Profile *ObjectReference              `json:"profile"`
   }
 
-- `Name` is required and specifies the action in the Blueprint.
-- `Object` is a required reference to the Kubernetes object on which
+- ``Name`` is required and specifies the action in the Blueprint.
+- ``Object`` is a required reference to the Kubernetes object on which
   the action will be performed.
-- `Blueprint` is a required name of the Blueprint that contains the
+- ``Blueprint`` is a required name of the Blueprint that contains the
    action to run.
-- `Artifacts` are input Artifacts passed to the Blueprint. This must
+- ``Artifacts`` are input Artifacts passed to the Blueprint. This must
   contain an Artifact for each name listed in the BlueprintAction's
   InputArtifacts.
-- `ConfigMaps` and `Secrets`, similar to `Artifacts`, are a mappings of names
+- ``ConfigMaps`` and ``Secrets``, similar to ``Artifacts``, are a mappings of names
   specified in the Blueprint referencing the Kubernetes object to be used.
-- `Profile` is a reference to a :ref:`Profile<profiles>` Kubernetes
+- ``Profile`` is a reference to a :ref:`Profile<profiles>` Kubernetes
   CustomResource that will be made available to the Blueprint.
-- `Options` is used to specify additional values to be used in the Blueprint
+- ``Options`` is used to specify additional values to be used in the Blueprint
 
 As a reference, below is an example of a ActionSpec.
 
@@ -229,8 +229,8 @@ which will stop the execution of the actions.
     actionset.cr.kanister.io "s3backup-j4z6f" deleted
 
 .. note::
-    Since ActionSets are `Custom Resources`, Kubernetes allows users to delete them like any other API objects.
-    Currently, `deleting` an ActionSet to stop execution is an **alpha** feature.
+    Since ActionSets are ``Custom Resources``, Kubernetes allows users to delete them like any other API objects.
+    Currently, *deleting* an ActionSet to stop execution is an **alpha** feature.
 
 .. _profiles:
 
@@ -240,7 +240,7 @@ Profiles
 Profile CRs capture information about a location for data operation artifacts
 and corresponding credentials that will be made available to a Blueprint.
 
-The definition of a `Profile` is:
+The definition of a ``Profile`` is:
 
 .. code-block:: go
   :linenos:
@@ -252,14 +252,14 @@ The definition of a `Profile` is:
     SkipSSLVerify     bool       `json:"skipSSLVerify"`
   }
 
-- `SkipSSLVerify` is boolean and specifies whether skipping SkipSSLVerify
-  verification is allowed when operating with the `Location`. If omitted from
-  a CR definition it default to `false`
-- `Location` is required and used to specify the location that the Blueprint
+- ``SkipSSLVerify`` is boolean and specifies whether skipping SkipSSLVerify
+  verification is allowed when operating with the ``Location``. If omitted from
+  a CR definition it default to ``false``
+- ``Location`` is required and used to specify the location that the Blueprint
   can use. Currently, only s3 compliant locations are supported. If any of
   the sub-components are omitted, they will be treated as "".
 
-  The definition of `Location` is as follows:
+  The definition of ``Location`` is as follows:
 
 .. code-block:: go
   :linenos:
@@ -282,11 +282,11 @@ The definition of a `Profile` is:
     Region   string       `json:"region"`
   }
 
-- `Credential` is required and used to specify the credentials associated with
-  the `Location`. Currently, only key pair s3, gcs and azure location credentials are
+- ``Credential`` is required and used to specify the credentials associated with
+  the ``Location``. Currently, only key pair s3, gcs and azure location credentials are
   supported.
 
-  The definition of `Credential` is as follows:
+  The definition of ``Credential`` is as follows:
 
 .. code-block:: go
   :linenos:
@@ -311,10 +311,10 @@ The definition of a `Profile` is:
     Secret      ObjectReference `json:"secret"`
   }
 
-- `IDField` and `SecretField` are required and specify the corresponding
-  keys in the secret under which the `KeyPair` credentials are stored.
-- `Secret` is required reference to a Kubernetes Secret object storing the
-  `KeyPair` credentials.
+- ``IDField`` and ``SecretField`` are required and specify the corresponding
+  keys in the secret under which the ``KeyPair`` credentials are stored.
+- ``Secret`` is required reference to a Kubernetes Secret object storing the
+  ``KeyPair`` credentials.
 
 As a reference, below is an example of a Profile and the corresponding secret.
 
@@ -359,7 +359,7 @@ Controller
 ==========
 
 The Kanister controller is a Kubernetes Deployment and is installed easily using
-`kubectl`. See :ref:`install` for more information on deploying the controller.
+``kubectl``. See :ref:`install` for more information on deploying the controller.
 
 Execution Walkthrough
 ---------------------
@@ -385,7 +385,7 @@ Within an ActionSet, individual Actions are run in parallel.
 Currently the user is responsible for cleaning up ActionSets once they complete.
 
 During execution, Kanister controller emits events to the respective ActionSets.
-In above example, the execution transitions of ActionSet `s3backup-j4z6f` can be
+In above example, the execution transitions of ActionSet ``s3backup-j4z6f`` can be
 seen by using the following command:
 
 .. code-block:: bash

docs/functions.rst

@@ -16,15 +16,15 @@ implements the following go interface:
       RequiredArgs() []string
   }
 
-Kanister Functions are registered by the return value of `Name()`, which must be
+Kanister Functions are registered by the return value of ``Name()``, which must be
 static.
 
-Each phase in a Blueprint executes a Kanister Function.  The `Func` field in
-a `BlueprintPhase` is used to lookup a Kanister Function.  After
-`BlueprintPhase.Args` are rendered, they are passed into the Kanister Function's
-`Exec()` method.
+Each phase in a Blueprint executes a Kanister Function.  The ``Func`` field in
+a ``BlueprintPhase`` is used to lookup a Kanister Function.  After
+``BlueprintPhase.Args`` are rendered, they are passed into the Kanister Function's
+``Exec()`` method.
 
-The `RequiredArgs` method returns the list of argument names that are required.
+The ``RequiredArgs`` method returns the list of argument names that are required.
 
 Existing Functions
 ==================
@@ -155,10 +155,10 @@ It is similar to running
 
 .. code-block:: bash
 
-  `kubectl scale deployment <DEPLOYMENT-NAME> --replicas=<NUMBER OF REPLICAS> --namespace <NAMESPACE>`
+  kubectl scale deployment <DEPLOYMENT-NAME> --replicas=<NUMBER OF REPLICAS> --namespace <NAMESPACE>
 
 This can be useful if the workload needs to be shutdown before processing
-certain data operations. For example, it may be useful to use `ScaleWorkload`
+certain data operations. For example, it may be useful to use ``ScaleWorkload``
 to stop a database process before restoring files.
 
 .. csv-table::
@@ -222,17 +222,17 @@ ScaleWorkload.
 
    `namespace`, Yes, `string`, namespace in which to execute
    `image`, Yes, `string`, image to be used the command
-   `volumes`, No, `map[string]string`, Mapping of `pvcName` to `mountPath` under which the volume will be available.
+   `volumes`, No, `map[string]string`, Mapping of ``pvcName`` to ``mountPath`` under which the volume will be available.
    `command`, Yes, `[]string`,  command list to execute
    `serviceaccount`, No, `string`,  service account info
 
 .. note::
-   The `volumes` argument does not support `subPath` mounts so the
-   data manipulation logic needs to be aware of any `subPath` mounts
+   The ``volumes`` argument does not support ``subPath`` mounts so the
+   data manipulation logic needs to be aware of any ``subPath`` mounts
    that may have been used when mounting a PVC in the primary
    application container.
-   If `volumes` argument is not specified, all volumes belonging to the protected object
-   will be mounted at the predefined path `/mnt/prepare_data/<pvcName>`
+   If ``volumes`` argument is not specified, all volumes belonging to the protected object
+   will be mounted at the predefined path ``/mnt/prepare_data/<pvcName>``
 
 Example:
 
@@ -268,7 +268,7 @@ This function backs up data from a container into any object store
 supported by Kanister.
 
 .. note::
-   It is important that the application includes a `kanister-tools`
+   It is important that the application includes a ``kanister-tools``
    sidecar container. This sidecar is necessary to run the
    tools that capture path on a volume and store it on the object store.
 
@@ -327,7 +327,7 @@ This function concurrently backs up data from one or more pods into an any
 object store supported by Kanister.
 
 .. note::
-   It is important that the application includes a `kanister-tools`
+   It is important that the application includes a ``kanister-tools``
    sidecar container. This sidecar is necessary to run the
    tools that capture path on a volume and store it on the object store.
 
@@ -409,18 +409,18 @@ and restores data to the specified path.
    `encryptionKey`, No, `string`, encryption key to be used during backups
 
 .. note::
-   The `image` argument requires the use of `kanisterio/kanister-tools`
+   The ``image`` argument requires the use of ``kanisterio/kanister-tools``
    image since it includes the required tools to restore data from
    the object store.
-   Between the `pod` and `volumes` arguments, exactly one argument
+   Between the ``pod`` and ``volumes`` arguments, exactly one argument
    must be specified.
 
 Example:
 
 Consider a scenario where you wish to restore the data backed up by the
 :ref:`backupdata` function. We will first scale down the application,
 restore the data and then scale it back up.
-For this phase, we will use the `backupInfo` Artifact provided by
+For this phase, we will use the ``backupInfo`` Artifact provided by
 backup function.
 
 .. substitution-code-block:: yaml
@@ -493,9 +493,9 @@ Example:
 
 Consider a scenario where you wish to restore the data backed up by the
 :ref:`backupdataall` function. We will first scale down the application,
-restore the data and then scale it back up. We will not specify `pods` in
+restore the data and then scale it back up. We will not specify ``pods`` in
 args, so this function will restore data on all pods concurrently.
-For this phase, we will use the `params` Artifact provided by
+For this phase, we will use the ``params`` Artifact provided by
 BackupDataAll function.
 
 .. substitution-code-block:: yaml
@@ -564,7 +564,7 @@ Outputs:
 
 Example:
 
-If the ActionSet `Object` is a PersistentVolumeClaim:
+If the ActionSet ``Object`` is a PersistentVolumeClaim:
 
 .. code-block:: yaml
   :linenos:
@@ -596,7 +596,7 @@ Example:
 
 Consider a scenario where you wish to delete the data backed up by the
 :ref:`backupdata` function.
-For this phase, we will use the `backupInfo` Artifact provided by backup function.
+For this phase, we will use the ``backupInfo`` Artifact provided by backup function.
 
 .. code-block:: yaml
   :linenos:
@@ -630,7 +630,7 @@ Example:
 
 Consider a scenario where you wish to delete all the data backed up by the
 :ref:`backupdataall` function.
-For this phase, we will use the `params` Artifact provided by backup function.
+For this phase, we will use the ``params`` Artifact provided by backup function.
 
 .. code-block:: yaml
   :linenos:
@@ -657,7 +657,7 @@ from an object store.
    `artifact`, Yes, `string`, artifact to be deleted from the object store
 
 .. note::
-   The Kubernetes job uses the `kanisterio/kanister-tools` image,
+   The Kubernetes job uses the ``kanisterio/kanister-tools`` image,
    since it includes all the tools required to delete the artifact
    from an object store.
 
@@ -696,7 +696,7 @@ Arguments:
    `pvcs`, No, `[]string`, list of names of PVCs to be backed up
    `skipWait`, No, `bool`, initiate but do not wait for the snapshot operation to complete
 
-When no PVCs are specified in the `pvcs` argument above, all PVCs in use by a
+When no PVCs are specified in the ``pvcs`` argument above, all PVCs in use by a
 Deployment or StatefulSet will be backed up.
 
 Outputs:
@@ -711,7 +711,7 @@ Outputs:
 Example:
 
 Consider a scenario where you wish to backup all PVCs of a deployment. The output
-of this phase is saved to an Artifact named `backupInfo`, shown below:
+of this phase is saved to an Artifact named ``backupInfo``, shown below:
 
 .. code-block:: yaml
   :linenos:

docs/install.rst

@@ -15,7 +15,7 @@ Prerequisites
 * `kubectl <https://kubernetes.io/docs/tasks/tools/install-kubectl/>`_ installed
   and setup
 
-* `helm <https://helm.sh>`_ installed and initialized using the command `helm init`
+* `helm <https://helm.sh>`_ installed and initialized using the command ``helm init``
 
 * :ref:`kanctl <tooling>` installed
 
@@ -27,7 +27,7 @@ Prerequisites
 Deploying via Helm
 ==================
 
-This will install the Kanister controller in the `kanister` namespace
+This will install the Kanister controller in the ``kanister`` namespace
 
 .. substitution-code-block:: bash
 
@@ -49,7 +49,7 @@ Building and Deploying from Source
 
 Use the following commands to build, package, and deploy the controller to your
 Kubernetes cluster. It will push the controller docker image to your docker repo
-`"<MY REGISTRY>"` and the controller will be deployed in the default namespace.
+``<MY REGISTRY>`` and the controller will be deployed in the default namespace.
 
 .. code-block:: bash
 
@@ -67,8 +67,8 @@ Deploy a Released Version
 -------------------------
 
 To deploy a released version of the controller, issue the command below. Modify
-the namespace fields in `bundle.yaml.in` to deploy in a namespace of your
-choice. By default, the controller will be deployed into the `default`
+the namespace fields in ``bundle.yaml.in`` to deploy in a namespace of your
+choice. By default, the controller will be deployed into the ``default``
 namespace.
 
 .. substitution-code-block:: bash