Cleanup
- Use doc8 to check rst files
- Add spellcheck and VOLTHA-specific dictionary, fix spelling
- Other formatting and content fixes
Change-Id: I1eea3ab6eba4ec34af0788a681f1e8cd258ea988
diff --git a/overview/deploy-physical.rst b/overview/deploy-physical.rst
index 510c9ae..1758f03 100644
--- a/overview/deploy-physical.rst
+++ b/overview/deploy-physical.rst
@@ -6,7 +6,8 @@
Quickstart
----------
-The quickstart assumes you POD is already correctly cabled, if not you can refer to :ref:`Physical_Layout`
+The quickstart assumes you POD is already correctly cabled, if not you can
+refer to :ref:`Physical_Layout`
Requires:
@@ -14,7 +15,8 @@
- `kind-voltha <https://github.com/ciena/kind-voltha>`_ cloned on your machine
-Enter the ``kind-voltha`` directory and execute this command (``kubectl`` must be installed and poiting to your cluster):
+Enter the ``kind-voltha`` directory and execute this command (``kubectl`` must
+be installed and pointing to your cluster):
.. code:: bash
@@ -26,13 +28,13 @@
TLDR;
-----
-Below are the complete steps to install a physical cluster. It assumes ``kubectl`` and ``helm`` commands are already
-available.
+Below are the complete steps to install a physical cluster. It assumes
+``kubectl`` and ``helm`` commands are already available.
Configure Helm
--------------
-Helm provide a capabilty to install and manage Kubernetes applications.
+Helm provide a capability to install and manage Kubernetes applications.
VOLTHA’s default deployment mechanism utilized Helm. Before Helm can be
used to deploy VOLTHA it must be initialized and the repositories that
container the artifacts required to deploy VOLTHA must be added to Helm.
@@ -52,7 +54,7 @@
ETCD Operator is a utility that allows applications to create and manage
ETCD key/value clusters as Kubernetes resources. VOLTHA utilizes this
utility to create its key/value store. *NOTE: it is not required that
-VOLTHA create its own datastore as VOLTHA can utilize and existing
+VOLTHA create its own datastore as VOLTHA can utilize an existing
datastore, but for this example VOLTHA will creates its own datastore*
.. code:: bash
@@ -62,7 +64,7 @@
Wait for operator pods
~~~~~~~~~~~~~~~~~~~~~~
-Before continuing the Kubernetes pods associated with ETCD Operator must
+Before continuing, the Kubernetes pods associated with ETCD Operator must
be in the ``Running`` state.
.. code:: bash
@@ -85,21 +87,20 @@
---------------------
To demonstrate the capability of VOLTHA other *partner* applications are
-required, such as ONOS. The followins sections describe how to install
+required, such as ONOS. The following sections describe how to install
and configure these *partner* applications.
-*NOTE: It is important to start ONOS before VOLTHA as if they are
-started in the reverse order ofagent sometimes does not connect to the
-SDN
+*NOTE: It is important to start ONOS before VOLTHA as if they are started in
+the reverse order the ``ofagent`` sometimes does not connect to the SDN
controller*\ `VOL-1764 <https://jira.opencord.org/browse/VOL-1764>`__.
ONOS (OpenFlow Controller)
~~~~~~~~~~~~~~~~~~~~~~~~~~
-VOLTHA exposes an OLT and its connected ONUs as an OpenFlow switch. To
-control that virtual OpenFlow switch an OpenFlow controller is required.
-For most VOLTHA deployments that controller is ONOS with a set of ONOS
-applications installed. To install ONOS use the following Helm command:
+VOLTHA exposes an OLT and its connected ONUs as an OpenFlow switch. To control
+that virtual OpenFlow switch an OpenFlow controller is required. For most
+VOLTHA deployments that controller is ONOS, with a set of ONOS applications
+installed. To install ONOS use the following Helm command:
.. code:: bash
@@ -146,7 +147,7 @@
The ONOS applications leverage the *Subscriber and Device Information
Store (SADIS)* when processing EAPOL and DHCP packets from VOLTHA
-controlled devices. In order for VOLTHA to function propperly SADIS
+controlled devices. In order for VOLTHA to function properly, SADIS
entries must be configured into ONOS.
The repository contains two example SADIS configuration that can be used
@@ -179,7 +180,7 @@
--namespace voltha --name voltha onf/voltha
During the install of the core VOLTHA components some containers may
-“crash” or restart. This is normal as there are dependencies, such as
+"crash" or restart. This is normal as there are dependencies, such as
the read/write cores cannot start until the ETCD cluster is established
and so they crash until the ETCD cluster is operational. Eventually all
the containers should be in a ``Running`` state as queried by the
@@ -225,7 +226,7 @@
Exposing VOLTHA Services
------------------------
-At this point VOLTHA is deployed and from within the Kubernetes cluster
+At this point VOLTHA is deployed, and from within the Kubernetes cluster
the VOLTHA services can be reached. However, from outside the Kubernetes
cluster the services cannot be reached.
@@ -244,7 +245,7 @@
Configure ``voltctl`` to Connect to VOLTHA
------------------------------------------
-In order for ``voltctl`` to connect to the VOLTHA instance deplpoyed in
+In order for ``voltctl`` to connect to the VOLTHA instance deployed in
the Kubernetes cluster it must know which IP address and port to use.
This configuration can be persisted to a local config file using the
following commands.
@@ -255,15 +256,11 @@
voltctl -a v2 -s localhost:55555 config > $HOME/.volt/config
To test the connectivity you can query the version of the VOLTHA client
-and server.
-
-.. code:: bash
+and server::
voltctl version
-The output should be similar to the following
-
-.. code:: bash
+The output should be similar to the following::
Client:
Version unknown-version
@@ -279,4 +276,4 @@
Vcs feference: 28f120f1f4751284cadccf73f2f559ce838dd0a5
Vcs dirty: false
Built: 2019-06-26T16:58:22Z
- OS/Arch: linux/amd64
\ No newline at end of file
+ OS/Arch: linux/amd64