ENDOC-464 Update the OpenShift Operator tutorial

vuepress/docs/next/docs/consume/operator-intro.md

@@ -3,39 +3,10 @@
 The Entando Operator processes the custom resources in Kubernetes that represent the different [components of an Entando application](../README.md).
 The goal of the operator is to provide automation and a set of default configuration options to simplify and accelerate the deployment of an Entando application.
 
-The sections below provide details and assumptions that the operator makes when deploying Entando Custom Resources. If you're using OpenShift these
+The sections below provide details and assumptions that the operator makes when deploying Entando Custom Resources. If you're using OpenShift, these
 sections will provide details on how to configure your deployment via the Operator Hub.
 
-For details on the individual custom resources and their configuration check out the [custom resources documentation](./custom-resources.md).
-
-## Installation Scope Options
-
-The Entando Operator can be installed in one of two modes. Either cluster scoped or namespace scoped. In a cluster scoped deployment the operator will have
-visibility across the cluster and will manage all of the Entando applications in the Kubernetes cluster. In a namespace scoped deployment the operator
-will only have visibility to the namespace where it is deployed and will manage only the components in that namespace.  
-
-When installing the operator via OpenShift look for the `Installation Mode` option to select the scoping for the operator.
-
-### When to use Cluster Scoped Deployments
-When choosing how to deploy your operator there are no right or wrong answers. Think about the deployment that best fits your goals and team. Here are some items to think about.
-
-- Cluster scoped deployments are common in production clusters and in environments with strong operational support and controls.
-- A cluster scoped deployment can saves resources When you want to optimize resource consumption and share Kubernetes infrastructure.
-- When you are planning to centralize and share other infrastructure resources like Keycloak and databases a cluster scoped deployment can fit into the same management processes.
-   - Sharing infrastructure resources is a recommended approach for medium or large teams and the operator can be treated like other infrastructure services.
-- In some cases security requirements will require that the permissions required for the operator are managed separately from the deployed applications. A cluster scoped deployment isolates the operator permissions in a separate namespace.
-- Cluster scoped deployments can simplify the deployment of an Entando app by developers or end users because they have fewer resources to manage
-
-###  When to use Namespace Scoped Deployments
-When choosing how to deploy your operator there are no right or wrong answers. Think about the deployment that best fits your goals and team. Here are some items to think about.
-
-- Namespace scoped deployments are common in dev clusters. Or in clusters where application naemspaces come and go frequently
-- Namespace scoped deployments are useful in scenarios where you plan to, or could have, many different versions of Entando
-- Namespace scoped deployments give your teams complete team autonomy and the ability to create and destroy applications
-- When teams are small and self managing from an operational perspective a namespace scoped deployment is a simpler architecture
-- If you plan to have a small number of applications deployed in the cluster a namespace scoped deployment can be easier to manage
-
-[Click here for tutorials on deploying via the Operator](../../tutorials/getting-started/openshift-install-by-operator.md)
+For details on the individual custom resources and their configuration check out the [custom resources documentation](./custom-resources.md). [See the for instructions here on deploying via the Operator](../../tutorials/getting-started/openshift-install-by-operator.md)
 
 ## TLS Secret Creation
 
@@ -46,25 +17,23 @@ When configuring and deploying Entando via the operator you will be asked to pro
 will be exposed on.
 - Refer to the 'ingressHostname' property in the custom resource for more information on how the hostname is
 determined.
-- If a secret isn't provided the Entando Operator will evaluate the value of the `ENTANDO_PATH_TO_TLS_KEYPAIR` which is
-expected to contain two files: tls.key and tls.crt.
-  - If a key pair is found in the folder specified, it will revert to the keypair found.
-  - If a key pair is not found the Entando Operator will evaluate the value of the `ENTANDO_USE_AUTO_CERT_GENERATION`.
+- If a secret isn't provided the Entando Operator will evaluate the value of the `ENTANDO_PATH_TO_TLS_KEYPAIR` which is expected to contain two files: tls.key and tls.crt.
+  - If a key pair is found in the folder specified, it will revert to the key pair found.
+  - If a key pair is not found, the Entando Operator will evaluate the value of the `ENTANDO_USE_AUTO_CERT_GENERATION`.
     If that property is set to `true`, the Entando Operator will assume that the cluster has been configured with a valid CA and leave it to
     the Ingress controller to generate its own certificates.
 
-[Click here for tutorials setting up TLS in your Entando Apps.](../../tutorials/getting-started/openshift-install-by-operator.md)
+[Click here for instructions on setting up TLS in your Entando Apps.](../../tutorials/getting-started/openshift-install-by-operator.md).
 
 ## Database Deployment
 
-Some Entando components include the ability to select a database management system (DBMS) when deploying the component.
+Some Entando components include the option to select a database management system (DBMS):
 
-- The DBMS field in Entando Custom Resources can be one of mysql, oracle, postgresql or embedded.
+- The value of the DBMS field in Entando Custom Resources can be mysql, oracle, postgresql or embedded.
   - **IMPORTANT!** -- If embedded is selected for a component, only one replica for the component can be created.
-  - **IMPORTANT!** -- Oracle instances are not supported for automatic deployment in a container. You must create an Oracle instance or use an existing instance and configure it as an [external database](../../tutorials/devops/external-db.md) for your Entando app
+  - **IMPORTANT!** -- Oracle instances are not supported for automatic deployment in a container. You must create your own Oracle instance or reuse an existing instance and then configure the [external database](../../tutorials/devops/external-db.md) for your EntandoApp.
 
-- If an EntandoDatabaseService has been deployed in the component's namespace, and the DBMS specified on this EntandoDatabaseService
- is the same as the DBMS specified on this EntandoApp, the Entando Operator will create dedicated
+- If an EntandoDatabaseService has been deployed in the component's namespace and the DBMS specified on this EntandoDatabaseService is the same as the DBMS specified on this EntandoApp, then the Entando Operator will create dedicated
  schemas (in the case of PostgreSQL or Oracle), or databases in the case of MySQL.
    - If a matching EntandoDatabaseService does not exist in this namespace, the Entando Operator
      will automatically deploy the appropriate container to host the DBMS specified. This last option is not
@@ -86,6 +55,5 @@ the documentation for each component's CRD to determine how each Entando resourc
 When deploying an Entando Custom Resource that uses an Ingress path:
 
 - The `ingressHostName` property defines the host path that will be used to access this
-  service from outside the cluster. The Entando Operator will
-  create an ingress reflecting this hostname, and expose the resource at its default path.
+  service from outside the cluster. The Entando Operator will create an ingress with this hostname and expose the resource at its default path.
 

vuepress/docs/next/tutorials/devops/entando-operator.md

@@ -3,16 +3,16 @@ sidebarDepth: 2
 ---
 
 # Configure the Entando Operator
-This tutorial demonstrates how to provide the Entando Operator with a ConfigMapto customize its behavior. See the template file below for possible settings related to timeouts, TLS/SSL configuration, and default image repository. Some specific tutorials (e.g. [Plugin Configuration Profiles](./plugin-configuration.md)) also require updates to the Entando Operator configuration.
+This tutorial demonstrates how to provide the Entando Operator with a ConfigMap to customize its behavior. See the template file below for possible settings related to image timeouts, TLS/SSL configuration, and the default image repository. Some specific tutorials (e.g. [Plugin Configuration Profiles](./plugin-configuration.md)) also require updates to the Entando Operator configuration.
 
 ## Prerequisites
-The Entando Operator makes use of an optional `ConfigMap` named `entando-operator-config`. It must be present in the same namespace as the Operator. In a quickstart environment, you can check for its presence with this command:
+The Entando Operator makes use of an optional ConfigMap named `entando-operator-config`. It must be present in the same namespace as the Operator. In a quickstart environment, you can check for its presence with this command:
 ```sh
 kubectl get configmap -n entando
 ```
 
 ## Add a new ConfigMap
-If the `ConfigMap` doesn't already exist, you can use a template as a starting point.
+If the ConfigMap doesn't already exist, you can use a template as a starting point.
 ```sh
 curl -sfL "https://raw.githubusercontent.com/entando/entando-releases/v7.0.0/dist/ge-1-1-6/samples/entando-operator-config.yaml"
 ```
@@ -23,14 +23,14 @@ Edit `entando-operator-config.yaml` to adjust existing settings or add new ones.
 kubectl apply -f entando-operator-config.yaml -n entando
 ```
 
-The Entando Operator automatically reloads the settings from the new `ConfigMap`. You can verify the reload by checking the logs in the operator pod.
+The Entando Operator automatically reloads settings from the ConfigMap when the ConfigMap is created. You can verify the reload by checking the logs in the operator pod.
 
 ## Update an existing ConfigMap
-If the `ConfigMap` already exists, you can edit the `ConfigMap` to adjust existing settings or add new ones.
+You can edit an existing ConfigMap to adjust existing settings or add new ones.
 ```sh 
 kubectl edit configmap/entando-operator-config -n entando
 ```
 
-The Entando Operator automatically reloads the settings from the `ConfigMap`. You can verify the reload by checking the logs in the operator pod. Some settings may only take effect when a deployment is first created, e.g. timeout settings or cpu limits.
+The Entando Operator automatically reloads settings from the ConfigMap whenever it is modified. You can verify the reload by checking the logs in the operator pod. Some settings may only take effect when a deployment is first created, e.g. timeout settings or CPU limits.
 
 

vuepress/docs/next/tutorials/getting-started/openshift-install-by-operator.md

@@ -20,7 +20,7 @@ oc apply -f https://raw.githubusercontent.com/entando/entando-releases/v7.0.0/di
 ```
 
 ## Scenario 1 - Embedded Database
-The initial scenario is to deploy the operator and Entando Application in a single namespace. We'll start with the smallest application footprint by using an embedded database although this is not recommended for production use cases.
+The initial scenario deploys the operator and Entando Application in a single namespace. We'll start with the smallest application footprint by using an embedded database, although this is not recommended for production use cases.
 1. Locate the `Entando Operator` in the `Operators` → `OperatorHub`. Make sure to select the appropriate version.
 2. Click `Install` to view the `Entando Operator` install options
 3. Select `A specific namespace on the cluster` for the `Installation mode`
@@ -30,9 +30,9 @@ The initial scenario is to deploy the operator and Entando Application in a sing
 7. Now go to `EntandoApp` and click `Create EntandoApp`
    - Keep the default `my-app` as your application name or select your own
    - Select the EntandoApp version: `7.0`
-8. Provide an `Ingress Host Name` specific to your namespace, e.g. `my-app.YOUR-BASE-OPENSHIFT-URL.` In CRC you can keep the default `entando.apps-crc.testing` for your first project.
+8. Provide an `Ingress Host Name` specific to your namespace, e.g. `my-app.YOUR-BASE-OPENSHIFT-URL`. In CRC you can keep the default `entando.apps-crc.testing` for your first project.
 9. Change the `DBMS` to `embedded`. This is the lightest and quickest way to test a full Entando Application. However, a non-embedded relational database is strongly recommended for production use.
-10. Click `Create`. The `Entando Operator` will now proceed to deploy the appropriate resources. 
+10. Click `Create`. The Entando Operator will now proceed to deploy the appropriate resources. 
 11. Go to `EntandoApp` → `my-app` to check the status of the deploy
 
 See the [Next Steps](#next-steps) below to continue your work with Entando.
@@ -45,7 +45,7 @@ Now let's create a new application, this time using PostgreSQL.
    - Keep the default `my-app` as your application name or select your own
    - Select the EntandoApp version: `7.0`
 2. Set the `Ingress Host Name` as in Scenario 1 above
-3. Keep the default `DBMS` as `postgresql`  
+3. Keep the default `DBMS` value of `postgresql`  
 4. Click `Create`. The `Entando Operator` will now proceed to deploy the appropriate resources as in Scenario 1 but with the addition of a PostgreSQL database deployment.
 
 See the [Next Steps](#next-steps) below to continue your work with Entando.
@@ -69,25 +69,25 @@ data:
 ```
 8. Click `Create`
 
-Now let's create a new application, just like in Scenario 2 but with OpenShift SSL in place.  
+Now let's create a new application similar to Scenario 2, but with OpenShift SSL in place.  
 
 9. Go to `EntandoApp` and click `Create instance`
    - Keep the default `my-app` as your application name or select your own
    - Select the EntandoApp version: `7.0`
    - Set the `Ingress Host Name` as in Scenario 1 above
-   - Keep the default `DBMS` as `postgresql`
-10. Click `Create`. The `Entando Operator` will now proceed to deploy the appropriate resources.
+   - Keep the default `DBMS` value of `postgresql`
+10. Click `Create`. The `Entando Operator` proceeds to deploy the appropriate resources.
 
-Once the deployment is complete you can confirm that all routes use https with OpenShift's CA. You will likely still see security warnings in the browser.
+Once the deployment is complete, you can confirm that all routes use HTTPS with OpenShift's CA. You will likely still see security warnings in the browser.
 
 See the [Next Steps](#next-steps) below to continue your work with Entando.
 
-## Scenario 4 - PostgreSQL plus self-signed SSL
-This scenario is similar to Scenario 3 but here you'll use a self-signed certificate rather than using OpenShift's Certificate Authority. As a starting point, you can either remove the EntandoApp and Provided Capabilities from the previous scenarios or prepare a new project per steps 1-5 in Scenario 1.
+## Scenario 4 - PostgreSQL plus Self-Signed SSL
+This scenario is similar to Scenario 3 but here you'll use a self-signed certificate instead of a certificate provided by OpenShift's internal Certificate Authority. As a starting point, you can either remove the EntandoApp and Provided Capabilities from the previous scenarios or prepare a new project per steps 1-5 in Scenario 1.
 
-We'll start by creating a self-signed certificate and then prepare the Secrets and ConfigMap to match. There are various ways to create an X.509 self-signed certificate so you can use your preferred mechanism.
+Start by creating a self-signed certificate and then prepare the Secrets and ConfigMap to match. There are various ways to create an X.509 self-signed certificate, so you can use your preferred mechanism.
 
-1. Using [OpenSSL](https://www.openssl.org/) create a certificate for your application. You'll need to adjust the CN value to match the Ingress Host Name for your project.
+1. Using [OpenSSL](https://www.openssl.org/), create a certificate for your application. You'll need to adjust the CN value to match the Ingress Host Name for your project.
 ```shell
 openssl req -nodes -x509 -newkey rsa:4096 -keyout tls.key -out tls.crt -days 365 -subj "/CN=entando.apps-crc.testing"
 ```
@@ -114,28 +114,28 @@ type: kubernetes.io/tls
 ```
 3. Click on `Actions` → `Edit Secret` and use the ```Browse...``` buttons to upload the key and cert files.
 
-Now you'll create the `entando-ca-cert-secret` Secret, similar to what was done in Scenario 3 but this time using the self-signed certificate. 
+Now create the `entando-ca-cert-secret` Secret, similar to what was done in Scenario 3, but this time using the self-signed certificate. 
 
 4. Go to `Workloads` → `Secrets` → `Create` and select `Key/value secret`
 5. Set the `Secret Name`, e.g. `entando-ca-cert-secret` 
 6. Set the `Key`, e.g. `tls.crt`
 7. Set the `Value` by clicking `Browse...` and loading the cert file from Step 1, e.g. `tls.crt`
 8. Click `Create`
-9. Next go to `Workloads` → `ConfigMaps` and update or create a ConfigMap named `entando-operator-config.` This is the ConfigMap used by the Operator to configure the deployments. You can [download the Entando Operator template](../devops/entando-operator.md#add-a-new-configmap) as a starting point. Set the "data/entando.ca.secret.name" and "data/entando.tls.secret.name" to match the names from above.
+9. Next, go to `Workloads` → `ConfigMaps` and update or create a ConfigMap named `entando-operator-config.` This is the ConfigMap used by the Operator to configure the deployments. You can [download the Entando Operator template](../devops/entando-operator.md#add-a-new-configmap) as a starting point. Set the "data/entando.ca.secret.name" and "data/entando.tls.secret.name" to match the names from above.
 ```yaml
 data:
  entando.ca.secret.name: entando-ca-cert-secret
  entando.tls.secret.name: entando-tls-secret
 ```
 10. Click `Create`
 
-Now let's create a new application, just like in Scenario 3 but with the self-signed SSL certificate.  
+Now let's create a new application similar to Scenario 3, but with the self-signed SSL certificate.  
 
 11. Go to `EntandoApp` and click `Create instance`
-  - Keep the default `my-app` for your application name or select your own
+  - Keep the default `my-app` as your application name or select your own
   - Select the EntandoApp version: `7.0`
-  - Set the `Ingress Host Name` as in Scenario 1 above. It should match the CN used to generate the cert in step 1.
-  - Keep the default `DBMS` as `postgresql`
+  - Set the `Ingress Host Name` as in Scenario 1 above. It should match the CN used to generate the certificate in step 1.
+  - Keep the default `DBMS` value as `postgresql`
 12. Click `Create`. The `Entando Operator` will now proceed to deploy the appropriate resources.
 
 Once the deployment is complete, you can confirm that all routes use HTTPS with the self-signed certificate. You will still see security warnings in the browser.
@@ -144,7 +144,7 @@ See the [Next Steps](#next-steps) below to continue your work with Entando.
 
 ## Next Steps
 Once you've completed any of the scenarios above, you have several options.
-*  Check out `Networking` → `Routes` to see the URLs for the running services. Common starting points include the `Entando App Builder` (e.g. `http://entando.apps-crc.testing/app-builder/`) or the `Entando Application` itself (e.g. `http://entando.apps-crc.testing/entando-de-app/`).
+*  Check out `Networking` → `Routes` to see the URLs for the running services. Common starting points include the Entando App Builder (e.g. `http://entando.apps-crc.testing/app-builder/`) or the Entando Application itself (e.g. `http://entando.apps-crc.testing/entando-de-app/`).
 * See the [Entando Operator Configuration](../devops/entando-operator.md) for options related to timeout settings and the default image registry.
 * This suggested [list of next steps](../../docs/getting-started/#next-steps) could also be useful.