docs: various small docs fixes (#683)

* various small docs fixes

* ~

* Apply suggestions from code review

* Update docs/modules/nifi/pages/index.adoc

---------

Co-authored-by: Malte Sander <[email protected]>

Author: fhennig

docs/modules/nifi/pages/getting_started/first_steps.adoc

@@ -1,7 +1,8 @@
 = First steps
 :description: Deploy Apache NiFi and ZooKeeper on Kubernetes using manifest files. Verify setup and access NiFi's web interface with stackablectl or kubectl.
 
-After going through the xref:getting_started/installation.adoc[] section and having installed all the operators, you will now deploy a NiFi cluster and the required dependencies. Afterwards you can <<_verify_that_it_works, verify that it works>> by querying the REST API.
+After going through the xref:getting_started/installation.adoc[] section and having installed all the operators, you deploy a NiFi cluster and the required dependencies.
+Afterward you can <<_verify_that_it_works, verify that it works>> by querying the REST API.
 
 == Setup
 
@@ -10,7 +11,8 @@ Two things need to be installed to create a NiFi cluster:
 * A ZooKeeper cluster for internal use by NiFi
 * The NiFi cluster itself
 
-We will create them in this order, each one is created by applying a manifest file. The operators you just installed will then create the resources according to the manifest.
+Create them in this order, each one is created by applying a manifest file.
+The operators create the resources according to the manifest.
 
 === Apache ZooKeeper
 
@@ -28,7 +30,7 @@ Create a Znode object:
 include::example$getting_started/getting_started.sh[tag=install-znode]
 ----
 
-The xref:zookeeper:znodes.adoc[ZNode] makes sure that the NiFi cluster will operate in its own separated directory in ZooKeeper.
+The xref:zookeeper:znodes.adoc[ZNode] makes sure that the NiFi cluster operates in its own separated directory in ZooKeeper.
 
 === Apache NiFi
 

docs/modules/nifi/pages/getting_started/index.adoc

@@ -1,12 +1,12 @@
 = Getting started
 :description: Get started with Apache NiFi using the Stackable operator: install, set up your cluster, and configure resources.
 
-This guide will get you started with Apache NiFi using the Stackable operator.
-It will guide you through the installation of the operator and its dependencies, setting up your first NiFi cluster.
+This guide gets you started with Apache NiFi using the Stackable operator.
+It guides you through the installation of the operator and its dependencies, setting up your first NiFi cluster.
 
 == Prerequisites
 
-You will need:
+You need:
 
 * a Kubernetes cluster
 * kubectl

docs/modules/nifi/pages/getting_started/installation.adoc

@@ -1,15 +1,12 @@
 = Installation
 :description: Install the Stackable operator for Apache NiFi and its dependencies using stackablectl or Helm. Follow steps for a complete setup on Kubernetes.
 
-On this page you will install the Stackable operator for Apache NiFi and operators for its dependencies - ZooKeeper -
+On this page you install the Stackable operator for Apache NiFi and operators for its dependencies -- ZooKeeper --
 as well as the commons, secret and listener operator which are required by all Stackable operators.
 
-== Stackable operators
-
-There are two ways to install Stackable operators:
-
-* Using xref:management:stackablectl:index.adoc[stackablectl]
-* Using Helm
+There are multiple ways to install the Stackable operators.
+xref:management:stackablectl:index.adoc[] is the preferred way, but Helm is also supported.
+OpenShift users may prefer installing the operator from the RedHat Certified Operator catalog using the OpenShift web console.
 
 [tabs]
 ====
@@ -52,8 +49,7 @@ Then install the Stackable operators:
 include::example$getting_started/getting_started.sh[tag=helm-install-operators]
 ----
 
-Helm will deploy the operators in a Kubernetes Deployment and apply the CRDs for the Apache NiFi service (as well as the CRDs for the required operators).
-You are now ready to deploy Apache NiFi in Kubernetes.
+Helm deploys the operators in a Kubernetes Deployment and applies the CRDs for the Apache NiFi service (as well as the CRDs for the required operators).
 --
 ====
 

docs/modules/nifi/pages/index.adoc

@@ -19,8 +19,8 @@ It supports a wide range of data sources, formats and features such as data prov
 == Getting started
 
 Get started with Apache NiFi and the Stackable operator by following the xref:getting_started/index.adoc[] guide.
-It will guide you through the xref:getting_started/installation.adoc[installation] process and xref:getting_started/first_steps.adoc[connect] to the NiFi web interface.
-Afterwards have a look at the xref:usage_guide/index.adoc[] to learn how to configure your NiFi instance to your needs or run some <<demos, demos>> to learn more about using NiFi with other components.
+It guides you through the xref:getting_started/installation.adoc[installation] process and xref:getting_started/first_steps.adoc[connect] to the NiFi web interface.
+Afterward, have a look at the xref:usage_guide/index.adoc[] to learn how to configure your NiFi instance to your needs or run some <<demos, demos>> to learn more about using NiFi with other components.
 
 == Operator model
 
@@ -49,7 +49,7 @@ The xref:demos:nifi-kafka-druid-earthquake-data.adoc[] and xref:demos:nifi-kafka
 == Supported versions
 
 The Stackable operator for Apache NiFi currently supports the NiFi versions listed below.
-To use a specific NiFi version in your NifiCluster, you have to specify an image - this is explained in the xref:concepts:product-image-selection.adoc[] documentation.
+To use a specific NiFi version in your NifiCluster, you have to specify an image -- this is explained in the xref:concepts:product-image-selection.adoc[] documentation.
 The operator also supports running images from a custom registry or running entirely customized images; both of these cases are explained under xref:concepts:product-image-selection.adoc[] as well.
 
 include::partial$supported-versions.adoc[]

docs/modules/nifi/pages/reference/commandline-parameters.adoc

@@ -23,7 +23,7 @@ stackable-nifi-operator run --product-config /foo/bar/properties.yaml
 
 *Multiple values:* false
 
-The operator will **only** watch for resources in the provided namespace `test`:
+The operator **only** watches for resources in the provided namespace `test`:
 
 [source]
 ----

docs/modules/nifi/pages/reference/environment-variables.adoc

@@ -36,7 +36,7 @@ docker run \
 
 *Multiple values:* false
 
-The operator will **only** watch for resources in the provided namespace `test`:
+The operator **only** watches for resources in the provided namespace `test`:
 
 [source]
 ----

docs/modules/nifi/pages/usage_guide/configuration-environment-overrides.adoc

@@ -3,10 +3,11 @@
 :nifi-docs: https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#system_properties
 :java-security-docs: https://docs.oracle.com/en/java/javase/11/security/java-security-overview1.html
 
-The NiFi cluster definition supports overriding configuration properties, environment variables, and Pod attributes. The configuration overrides can be applied either per role, or per role group where the more specific override (role group) has precedence over the less specific one (role).
+The NiFi cluster definition supports overriding configuration properties, environment variables, and Pod attributes.
+The configuration overrides can be applied either per role, or per role group where the more specific override (role group) has precedence over the less specific one (role).
 
 IMPORTANT: Do not override port numbers.
-This will lead to cluster malfunction.
+This leads to cluster malfunction.
 
 == Configuration overrides
 
@@ -22,7 +23,7 @@ The following files can be edited directly via the `configOverrides` mechanism:
 
 Overrides are key-value pairs defined under one of the configuration files from the list above.
 They must match the property names as expected by NiFi.
-In the example below, a property `nifi.flow.configuration.archive.enabled` is being explicitly set to 'false', overriding the default value.
+In the example below, a property `nifi.flow.configuration.archive.enabled` is being explicitly set to `false`, overriding the default value.
 
 The following snippet shows how to disable workflow file backups in the NifiCluster definition:
 

docs/modules/nifi/pages/usage_guide/custom_processors.adoc

@@ -2,8 +2,7 @@
 :description: Load custom NiFi components by using custom Docker images or mounting external volumes with nar files for enhanced functionality.
 :nifi-docs-custom-components: https://nifi.apache.org/docs/nifi-docs/html/developer-guide.html#introduction
 
-It is possible to develop {nifi-docs-custom-components}[custom components] for Apache NiFi to extend the available functionality - most often this will probably be custom processors.
-
+You can develop {nifi-docs-custom-components}[custom components] for Apache NiFi, typically custom processors, to extend its functionality.
 For these to be available in the NiFi UI, they need to be present in the classpath at startup, so the nar bundles have to be injected into your NiFi instance.
 
 The Stackable Data Platform supports two ways to achive this goal, both of which are described below.
@@ -12,8 +11,8 @@ Please note that building your own Docker image is the recommended solution, as
 
 == Custom Docker image
 
-You can extend the official Stackable NiFi image and copy all required _nar_ files into the classpath of Nifi.
-The benefit of this method is that there is no need for any config overrides or extra mounts, you can use any of our NiFi examples, swap the image and your components will be available.
+You can extend the official Stackable NiFi image by copying the required _nar_ files into NiFi's classpath.
+The benefit of this method is that there is no need for any config overrides or extra mounts, you can use any of the NiFi examples, swap the image and your components will be available.
 But this means you will need to have access to a registry to push your custom image to.
 
 The basic Dockerfile below shows how to achieve this:
@@ -40,7 +39,7 @@ Also read the xref:guides:custom-images.adoc[Using customized product images] gu
 If you don't want to create a custom image or don't have access to an image registry, you can use the extra volume mount functionality to mount a volume containing your custom components and configure NiFi to read these from the mounted volumes.
 
 For this to work you'll need to prepare a PersistentVolumeClaim (PVC) containing your components.
-Usually the best way to do this will be to mount the PVC into a temporary container and then `kubectl cp` the _nar_ files into that volume.
+Usually the best way to do this is to mount the PVC into a temporary container and then `kubectl cp` the _nar_ files into that volume.
 
 The following listing shows an example of creating the PVC and the Pod:
 
@@ -78,7 +77,8 @@ spec:
           name: nifi-processor
 ----
 
-<1> Please note that this access mode will mean that you can only use this volume with a single NiFi Pod. For a distributed scenario, an additional list value of `ReadOnlyMany` could be specified here if this is supported.
+<1> Please note that this access mode means that you can only use this volume with a single NiFi Pod.
+    For a distributed scenario, an additional list value of `ReadOnlyMany` could be specified here if this is supported.
 
 The command to then copy the nar bundle into the PVC is:
 
@@ -89,7 +89,7 @@ kubectl cp /path/to/component.nar processorcopy:/volume/
 
 Now you can mount the extra volume into your NiFi instance as described in xref:nifi:usage_guide/extra-volumes.adoc[].
 
-After this is done your components will be available within the NiFi Pods and NiFi can be configured to load these at startup by adding an extra directory to the classpath:
+After this is done, your components are available within the NiFi Pods and NiFi can be configured to load these at startup by adding an extra directory to the classpath:
 
 
 [source,yaml]

docs/modules/nifi/pages/usage_guide/external_ports.adoc

@@ -36,8 +36,8 @@ spec:
       targetPort: 8123
 ----
 
-Depending on the Kubernetes configuration this snippet will request and external ip address and open port 8080 on that ip address.
-Any requests to this port will be forwarded to port 8123 on the NiFi pods - and thus the processor.
+Depending on the Kubernetes configuration this snippet requests an external IP address and opens port 8080 on that IP address.
+Any requests to this port are forwarded to port 8123 on the NiFi pods -- and thus the processor.
 
 If LoadBalancer Services or Ingress resources are not available for use, a NodePort Service would be an alternative:
 

docs/modules/nifi/pages/usage_guide/extra-volumes.adoc

@@ -4,7 +4,7 @@
 Since Apache NiFi allows executing arbitrary workflows depending on which processors are used, it may become necessary to add external files to the Pods.
 These could for example be client certificates used to configure a `PollHTTP` processor, a keytab to obtain a Kerberos ticket, or similar things.
 
-In order to make these files available the operator allows specifying extra volumes that will be added to the NiFi pods.
+In order to make these files available the operator allows specifying extra volumes that are added to the NiFi Pods.
 
 [source,yaml]
 ----
@@ -16,4 +16,4 @@ spec:
           secretName: nifi-client-certs
 ----
 
-All `Volumes` specified in this section will be made available under `/stackable/userdata/\{volumename\}`.
+All Volumes specified in this section are made available under `/stackable/userdata/\{volumename\}`.