From 091a60f9d0f3f3f1eeafda51e1a29b075abc614b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stephan=20Mei=C3=9Fl?= <stephan.meissl@eox.at>
Date: Mon, 29 Jun 2020 18:43:03 +0200
Subject: [PATCH] minor fixes
---
documentation/operator-guide/management.rst | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/documentation/operator-guide/management.rst b/documentation/operator-guide/management.rst
index 2b247691..3ff35d86 100644
--- a/documentation/operator-guide/management.rst
+++ b/documentation/operator-guide/management.rst
@@ -3,14 +3,14 @@
Service Management
==================
-This section shows how a deployed VS stack can be interacted with.
+This section shows how a deployed VS stack can and should be interacted with.
Scaling
-------
Scaling is a handy tool to ensure stable performance, even when dealing with
-higher usage on either service. For example, the preprocessor and registrar can
+higher usage on any service. For example, the preprocessor and registrar can
be scaled to a higher replica count to enable a better throughput when
ingesting data into the VS.
@@ -44,14 +44,16 @@ restart the individual instances of the services after pulling a newer image usi
docker service update --force <stack-name>_<service-name>
Updating configurations or environment files
----------------
+--------------------------------------------
Updating the service configurations or environment files used can not be done just by
-rescaling the impacted services to 0 and rerunning. The whole stack needs to be shut down using a command:
+rescaling the impacted services to 0 and rerunning. The whole stack needs to be shut down using the command:
.. code-block:: bash
docker stack rm <stack-name>
-A new deployment of the stack will already have updated configuration. The above mentioned process necessarily
-involved a certain service downtime between shutting down of the stack and new deployment.
+A new deployment of the stack will use the updated configuration. The above mentioned process necessarily
+involves a certain service downtime between shutting down of the stack and new deployment.
+
+The next section :ref:`ingestion` explains how to get data into the VS.
--
GitLab