ENDOC-464 Update the OpenShift Operator tutorial

vuepress/docs/.vuepress/next.js

@@ -205,8 +205,8 @@ module.exports = {
                                 path: path + 'getting-started/openshift-install.md'
                             },
                             {
-                                title: 'Red Hat OpenShift using the OperatorHub',
-                                path: path  + 'getting-started/openshift-install-by-operator-hub.md'
+                                title: 'Red Hat OpenShift using the Operator',
+                                path: path  + 'getting-started/openshift-install-by-operator.md'
                             },
                             {
                                 title: 'Amazon Elastic Kubernetes Service (EKS)',

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

@@ -3,74 +3,36 @@
 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
-sections will provide details on how to configure your deployment via the Operator Hub.
+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 and instructions for deploying via operator hub](../../tutorials/getting-started/openshift-install-by-operator-hub.md)
+For details on the individual custom resources and their configuration, check out the [custom resources documentation](./custom-resources.md). [See the instructions here on deploying via the Entando Operator](../../tutorials/getting-started/openshift-install-by-operator.md).
 
 ## TLS Secret Creation
 
-When configuring and deploying Entando via the operator you will be asked to provide a secret for some of the components in the architecture. A few things to be aware of when creating and configuring a secret:
+When configuring and deploying Entando via the operator, you will be asked to provide a secret for some of the components in the architecture. A few things to be aware of when creating and configuring a Secret:
 
-- The secret is assumed to be in the same namespace as the component being created.
-- This secret is expected to have a private key, and a certificate for the hostname (or a wildcard cert) that the service
-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 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.
+- The Secret is assumed to be in the same namespace as the component being created.
+- This Secret is expected to have a private key, and a certificate for the hostname (or a wildcard certificate) that the service 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, the operator will use that key pair.
+  - 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 Certificate Authority (CA) and leave it to the Ingress controller to generate its own certificates.
 
-[Click here for tutorials on creating secrets and setting up TLS in your Entando Apps.](../../tutorials/getting-started/openshift-install-by-operator-hub.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.
-  - **IMPORTANT!** -- If embedded is selected for a component only 1 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
+- 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 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 for this EntandoDatabaseService is the same as the DBMS specified for 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
-     yet supported for Oracle.
-- For an EntandoApp three schemas/database will be created: the Entando Port DB, tne Entando Serv DB and a database for
- the Entando Component Manager.
+     will automatically deploy the appropriate container to host the DBMS specified. This last option is not yet supported for Oracle.
+- For an EntandoApp, three schemas/databases will be created: the Entando Port DB, tne Entando Serv DB and a database for the Entando Component Manager.
    - If the Port and Serv schemas/databases are empty, the Entando Operator  will use the underlying Entando App to populate these databases with the data backup available in the standard backup path in the WAR deployment.
   - In scenarios where the EntandoApp needs to connect to an existing database that is fully managed
    by the customer, it is best to setup the standard database connection variables using the
@@ -86,8 +48,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.
-    - **IMPORTANT!** -- If omitted, the Entando Operator will automatically generate a hostname
-      using the value of the ENTANDO_DEFAULT_ROUTING_SUFFIX environment variable that the Entando Operator was
-      configured with. It will prefix the name and namespace of the EntandoKeycloakServer to this default routing suffix.
+  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,34 +3,34 @@ sidebarDepth: 2
 ---
 
 # Configure the Entando Operator
-This tutorial demonstrates how to provide a ```ConfigMap``` for the Entando Operator to customize its behavior.
+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. 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`. The ConfigMap 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"
 ```
 
-Edit ```entando-operator-config.yaml``` to adjust existing settings or add new ones. You can then apply it to Kubernetes.
+Edit `entando-operator-config.yaml` to adjust existing settings or add new ones. You can then apply it to Kubernetes.
 
 ```sh
 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 add or update settings.
 ```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.