From fdfca4b0fbddff73a874805218cf0613f7154be8 Mon Sep 17 00:00:00 2001
From: Tin Lam <tin@irrational.io>
Date: Fri, 25 May 2018 16:38:27 -0500
Subject: [PATCH] Fix handful of trivial items in docs
This fixes up typographical errors, capitalization issues and minor
stylistic formatting in the documentations.
Change-Id: I1951a90d48cc22e7f8c0516fc53f4018ef0a9a5d
Signed-off-by: Tin Lam <tin@irrational.io>
---
doc/source/devref/endpoints.rst | 2 +-
doc/source/devref/fluent-logging.rst | 6 +++---
doc/source/devref/pod-disruption-budgets.rst | 2 +-
doc/source/devref/upgrades.rst | 2 +-
doc/source/install/developer/cleaning-deployment.rst | 2 +-
doc/source/install/developer/deploy-with-ceph.rst | 2 +-
.../install/developer/kubernetes-and-common-setup.rst | 2 +-
doc/source/install/multinode.rst | 4 ++--
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/doc/source/devref/endpoints.rst b/doc/source/devref/endpoints.rst
index 414a35ab34..ea7fa83e19 100644
--- a/doc/source/devref/endpoints.rst
+++ b/doc/source/devref/endpoints.rst
@@ -101,5 +101,5 @@ various namespaces.
By default, each endpoint is located in the same namespace as the current
service's helm chart. To connect to a service which is running in a different
-kubernetes namespace, a ``namespace`` can be provided to each individual
+Kubernetes namespace, a ``namespace`` can be provided to each individual
endpoint.
diff --git a/doc/source/devref/fluent-logging.rst b/doc/source/devref/fluent-logging.rst
index 78e6b0fafd..95e985b518 100644
--- a/doc/source/devref/fluent-logging.rst
+++ b/doc/source/devref/fluent-logging.rst
@@ -6,7 +6,7 @@ Logging Requirements
OpenStack-Helm defines a centralized logging mechanism to provide insight into
the the state of the OpenStack services and infrastructure components as
-well as underlying kubernetes platform. Among the requirements for a logging
+well as underlying Kubernetes platform. Among the requirements for a logging
platform, where log data can come from and where log data need to be delivered
are very variable. To support various logging scenarios, OpenStack-Helm should
provide a flexible mechanism to meet with certain operation needs.
@@ -20,14 +20,14 @@ Especially, Fluent-bit is used as a log forwarder and Fluentd is used as a main
log aggregator and processor.
Fluent-bit, Fluentd meet OpenStack-Helm's logging requirements for gathering,
-aggregating, and delivering of logged events. Flunt-bit runs as a daemonset on
+aggregating, and delivering of logged events. Fluent-bit runs as a daemonset on
each node and mounts the `/var/lib/docker/containers` directory. The Docker
container runtime engine directs events posted to stdout and stderr to this
directory on the host. Fluent-bit then forward the contents of that directory to
Fluentd. Fluentd runs as deployment at the designated nodes and expose service
for Fluent-bit to forward logs. Fluentd should then apply the Logstash format to
the logs. Fluentd can also write kubernetes and OpenStack metadata to the logs.
-Fluentd will then forward the results to Elasticsearch and to optionally kafka.
+Fluentd will then forward the results to Elasticsearch and to optionally Kafka.
Elasticsearch indexes the logs in a logstash-* index by default. Kafka stores
the logs in a ``logs`` topic by default. Any external tool can then consume the
``logs`` topic.
diff --git a/doc/source/devref/pod-disruption-budgets.rst b/doc/source/devref/pod-disruption-budgets.rst
index 26a07ef9e5..d9a6d9721a 100644
--- a/doc/source/devref/pod-disruption-budgets.rst
+++ b/doc/source/devref/pod-disruption-budgets.rst
@@ -13,7 +13,7 @@ to a templated variable inside the ``values.yaml`` file.
The ``min_available`` within each service's ``values.yaml`` file can be
represented by either a whole number, such as ``1``, or a percentage,
such as ``80%``. For example, when deploying 5 replicas of a pod (such as
-keystone-api), using ``min_available: 3`` would enfore policy to ensure at
+keystone-api), using ``min_available: 3`` would enforce policy to ensure at
least 3 replicas were running, whereas using ``min_available: 80%`` would ensure
that 4 replicas of that pod are running.
diff --git a/doc/source/devref/upgrades.rst b/doc/source/devref/upgrades.rst
index d90025e087..10dd7cfe9e 100644
--- a/doc/source/devref/upgrades.rst
+++ b/doc/source/devref/upgrades.rst
@@ -63,7 +63,7 @@ with rolling update strategies:
maxSurge: {{ .Values.upgrades.rolling_update.max_surge }}
{{ end }}
-In values.yaml in each chart, the same defaults are supplied in every
+In ``values.yaml`` in each chart, the same defaults are supplied in every
chart, which allows the operator to override at upgrade or deployment
time.
diff --git a/doc/source/install/developer/cleaning-deployment.rst b/doc/source/install/developer/cleaning-deployment.rst
index 1b788b9d78..3ce95e90b8 100644
--- a/doc/source/install/developer/cleaning-deployment.rst
+++ b/doc/source/install/developer/cleaning-deployment.rst
@@ -18,7 +18,7 @@ All OpenStack projects can be configured such that upon deletion, their database
will also be removed. To delete the database when the chart is deleted the
database drop job must be enabled before installing the chart. There are two
ways to enable the job, set the job_db_drop value to true in the chart's
-values.yaml file, or override the value using the helm install command as
+``values.yaml`` file, or override the value using the helm install command as
follows:
.. code-block:: shell
diff --git a/doc/source/install/developer/deploy-with-ceph.rst b/doc/source/install/developer/deploy-with-ceph.rst
index ec802f70f3..988c701b07 100644
--- a/doc/source/install/developer/deploy-with-ceph.rst
+++ b/doc/source/install/developer/deploy-with-ceph.rst
@@ -19,7 +19,7 @@ Alternatively, this step can be performed by running the script directly:
./tools/deployment/developer/ceph/040-ceph.sh
-Activate the openstack namespace to be able to use Ceph
+Activate the OpenStack namespace to be able to use Ceph
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. literalinclude:: ../../../../tools/deployment/developer/ceph/045-ceph-ns-activate.sh
diff --git a/doc/source/install/developer/kubernetes-and-common-setup.rst b/doc/source/install/developer/kubernetes-and-common-setup.rst
index 11fb222489..b47b4d46bb 100644
--- a/doc/source/install/developer/kubernetes-and-common-setup.rst
+++ b/doc/source/install/developer/kubernetes-and-common-setup.rst
@@ -28,7 +28,7 @@ should be cloned:
.. note::
This installation, by default will use Google DNS servers, 8.8.8.8 or 8.8.4.4
- and updates resolv.conf. These DNS nameserver entries can be changed by
+ and updates ``resolv.conf``. These DNS nameserver entries can be changed by
updating file ``/opt/openstack-helm-infra/tools/images/kubeadm-aio/assets/opt/playbooks/vars.yaml``
under section ``external_dns_nameservers``.
diff --git a/doc/source/install/multinode.rst b/doc/source/install/multinode.rst
index 6c2bc0c9b3..6110d6d9e3 100644
--- a/doc/source/install/multinode.rst
+++ b/doc/source/install/multinode.rst
@@ -5,7 +5,7 @@ Multinode
Overview
========
-In order to drive towards a production-ready Openstack solution, our
+In order to drive towards a production-ready OpenStack solution, our
goal is to provide containerized, yet stable `persistent
volumes <https://kubernetes.io/docs/concepts/storage/persistent-volumes/>`_
that Kubernetes can use to schedule applications that require state,
@@ -81,7 +81,7 @@ you intend to join the cluster.
the ``ssh-copy-id`` command, for example: *ssh-copy-id
ubuntu@192.168.122.178*
3. Copy the key: ``sudo cp ~/.ssh/id_rsa /etc/openstack-helm/deploy-key.pem``
- 4. Set correct owenership: ``sudo chown ubuntu
+ 4. Set correct ownership: ``sudo chown ubuntu
/etc/openstack-helm/deploy-key.pem``
Test this by ssh'ing to a node and then executing a command with