Merge branch 'fix-spelling' into 'main'

misc: fix grammar and spelling in md,sh,txt files

See merge request weblogic-cloud/weblogic-kubernetes-operator!4936

(cherry picked from commit 8994303)

21efa6c misc: fix grammar and spelling in md,sh,txt files

Author: rjeberhard

README.md

@@ -2,7 +2,7 @@
 
 The WebLogic Kubernetes Operator (the “operator”) supports running your WebLogic Server and Fusion Middleware Infrastructure domains on Kubernetes, an industry standard, cloud neutral deployment platform. It lets you encapsulate your entire WebLogic Server installation and layered applications into a portable set of cloud neutral images and simple resource description files. You can run them on any on-premises or public cloud that supports Kubernetes where you've deployed the operator.
 
-Furthermore, the operator is well suited to CI/CD processes. You can easily inject changes when moving between environments, such as from test to production. For example, you can externally inject database URLs and credentials during deployment or you can inject arbitrary changes to most WebLogic configurations.
+Furthermore, the operator is well suited to CI/CD processes. You can easily inject changes when moving between environments, such as from test to production. For example, you can externally inject database URLs and credentials during deployment, or you can inject arbitrary changes to most WebLogic configurations.
 
 The operator takes advantage of the [Kubernetes operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/), which means that it uses Kubernetes APIs to provide support for operations, such as: provisioning, lifecycle management, application versioning, product patching, scaling, and security. The operator also enables the use of tooling that is native to this infrastructure for monitoring, logging, tracing, and security.
 

documentation/site/content/_index.md

@@ -2,7 +2,7 @@
 
 The WebLogic Kubernetes Operator (the “operator”) supports running your WebLogic Server and Fusion Middleware Infrastructure domains on Kubernetes, an industry standard, cloud neutral deployment platform. It lets you encapsulate your entire WebLogic Server installation and layered applications into a portable set of cloud neutral images and simple resource description files. You can run them on any on-premises or public cloud that supports Kubernetes where you've deployed the operator.
 
-Furthermore, the operator is well suited to CI/CD processes. You can easily inject changes when moving between environments, such as from test to production. For example, you can externally inject database URLs and credentials during deployment or you can inject arbitrary changes to most WebLogic configurations.
+Furthermore, the operator is well suited to CI/CD processes. You can easily inject changes when moving between environments, such as from test to production. For example, you can externally inject database URLs and credentials during deployment, or you can inject arbitrary changes to most WebLogic configurations.
 
 The operator takes advantage of the [Kubernetes operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/), which means that it uses Kubernetes APIs to provide support for operations, such as: provisioning, lifecycle management, application versioning, product patching, scaling, and security. The operator also enables the use of tooling that is native to this infrastructure for monitoring, logging, tracing, and security.
 

documentation/site/content/faq/domain-secret-mismatch.md

@@ -36,7 +36,7 @@ The error occurs while rolling pods have containers based on a new container ima
 
 The problem is that WebLogic cannot support server instances being part of the same WebLogic domain if the server instances do
 not all share the same domain-specific encryption key. Additionally, operator introspection
-currently happens only when starting servers following a total shutdown. Therefore, the `boot.properites` files generated from
+currently happens only when starting servers following a total shutdown. Therefore, the `boot.properties` files generated from
 introspecting the image containing the original domain directory will be invalid when used with a container started with
 the updated container image containing the new or unrelated domain directory.
 

documentation/site/content/introduction/architecture.md

@@ -113,7 +113,7 @@ The following diagram shows how the various parts of a WebLogic domain are manif
 This diagram shows the following details:
 
 *	An optional, persistent volume is created by the customer using one of the available providers.  If the persistent volume is shared across the domain or members of a cluster, then the chosen provider must support “Read Write Many” access mode.  The shared state on the persistent volume may include the `domain` directory, the `applications` directory, a directory for storing logs, and a directory for any file-based persistence stores.
-*	A pod is created for the WebLogic Server Administration Server.  This pod is named `DOMAIN_UID-wlservername` and is labeled with `weblogic.domainUID`, `weblogic.serverName`, and `weblogic.domainName`.  One container runs in this pod.  WebLogic Node Manager and Administration Server processes are run inside this container.  The Node Manager process is used as an internal implementation detail for the liveness probe which we will descibe in more detail later, for patching, and to provide monitoring and control capabilities to the Administration Console.  It is not intended to be used for other purposes, and it may be removed in some future release.
+*	A pod is created for the WebLogic Server Administration Server.  This pod is named `DOMAIN_UID-wlservername` and is labeled with `weblogic.domainUID`, `weblogic.serverName`, and `weblogic.domainName`.  One container runs in this pod.  WebLogic Node Manager and Administration Server processes are run inside this container.  The Node Manager process is used as an internal implementation detail for the liveness probe which we will describe in more detail later, for patching, and to provide monitoring and control capabilities to the Administration Console.  It is not intended to be used for other purposes, and it may be removed in some future release.
 *	A `ClusterIP` type service is created for the Administration Server pod.  This service provides a stable, well-known network (DNS) name for the Administration Server.  This name is derived from the `domainUID` and the Administration Server name as described [here](#network-name-predictability), and it is known before starting up any pod.  The Administration Server `ListenAddress` is set to this well-known name.  `ClusterIP` type services are only visible inside the Kubernetes cluster.  They are used to provide the well-known names that all of the servers in a domain use to communicate with each other.  This service is labeled with `weblogic.domainUID` and `weblogic.domainName`.
 *	A `NodePort` type service is optionally created for the Administration Server pod.  This service provides HTTP access to the Administration Server to clients that are outside the Kubernetes cluster.  This service is intended to be used to access the WebLogic Server Administration Console or for the T3 protocol for WLST connections.  This service is labeled with `weblogic.domainUID` and `weblogic.domainName`.
 *	A pod is created for each WebLogic Server Managed Server.  These pods are named `DOMAIN_UID-wlservername` and are labeled with `weblogic.domainUID`, `weblogic.serverName`, and `weblogic.domainName`.  One container runs in each pod.  WebLogic Node Manager and Managed Server processes are run inside each of these containers.  The Node Manager process is used as an internal implementation detail for the liveness probe which we will describe in more detail later.  It is not intended to be used for other purposes, and it may be removed in some future release.

documentation/site/content/managing-domains/configoverrides/_index.md

@@ -33,7 +33,7 @@ You can use overrides to customize domains as they are moved from QA to producti
   * Set your domain `configuration.secrets` to reference the aforementioned Secrets.
 * If your configuration overrides modify non-dynamic MBean attributes and you currently have WebLogic Server instances from this domain running:
   * Decide if the changes you are making to non-dynamic MBean attributes can be applied by rolling the affected clusters or Managed Server instances or if the change required a full domain shutdown.
-  * If a full domain shut down is requried, stop all running WebLogic Server instance Pods in your domain and then restart them. (See [Starting and stopping servers]({{< relref "/managing-domains/domain-lifecycle/startup/_index.md#starting-and-stopping-servers" >}}).)
+  * If a full domain shut down is required, stop all running WebLogic Server instance Pods in your domain and then restart them. (See [Starting and stopping servers]({{< relref "/managing-domains/domain-lifecycle/startup/_index.md#starting-and-stopping-servers" >}}).)
   * Otherwise, simply restart your domain, which includes rolling clusters. (See [Restarting servers]({{< relref "/managing-domains/domain-lifecycle/startup/_index.md#restarting-servers" >}}).)
 * Verify your overrides are taking effect.  (See [Debugging](#debugging)).
 
@@ -331,7 +331,7 @@ Best practices for data source modules and their overrides:
 * Changes to configuration overrides, including the contents of the ConfigMap containing the override templates or the contents of referenced Secrets, do not take effect until the operator runs or repeats its [introspection]({{< relref "/managing-domains/domain-lifecycle/introspection.md" >}}) of the WebLogic domain configuration.
 * If your configuration overrides modify non-dynamic MBean attributes and you currently have WebLogic Server instances from this domain running:
   * Decide if the changes you are making to non-dynamic MBean attributes can be applied by rolling the affected clusters or Managed Server instances, or if the change requires a full domain shutdown. (See [Overrides distribution](#overrides-distribution))
-  * If a full domain shut down is requried, stop all running WebLogic Server instance Pods in your domain and then restart them. (See [Starting and stopping servers]({{< relref "/managing-domains/domain-lifecycle/startup/_index.md#starting-and-stopping-servers" >}}).)
+  * If a full domain shut down is required, stop all running WebLogic Server instance Pods in your domain and then restart them. (See [Starting and stopping servers]({{< relref "/managing-domains/domain-lifecycle/startup/_index.md#starting-and-stopping-servers" >}}).)
   * Otherwise, simply restart your domain, which includes rolling clusters. (See [Restarting servers]({{< relref "/managing-domains/domain-lifecycle/startup/_index.md#restarting-servers" >}}).)
 * See [Debugging](#debugging) for ways to check if the configuration overrides are taking effect or if there are errors.
 

documentation/site/content/managing-domains/domain-lifecycle/scaling.md

@@ -358,7 +358,7 @@ roleRef:
 ```
 
 #### Horizontal Pod Autoscaler (HPA) using WebLogic Exporter Metrics
-Please read this blog post to learn how to scale a WebLogic cluster, based on WebLogic metrics provided by the Monitoring Exporter, using the Kubernetes Horizontal Pod Autoscaler (HPA). We will use the Prometheus Adapter to gather the names of the available metrics from Prometheus at regular intervals. A custom configuration of the adapter will expose only metrics that follow specific formats. [Horizontal Pod Autoscaler (HPA) using WebLogic Exporter Metrics](https://blogs.oracle.com/weblogicserver/post/horizontal-pod-autoscaler-hpausing-weblogic-exporter-metrics). See this corresponding video for a demonstation of the blog post in action. [WebLogic Kubernetes Operator support for Kubernetes Horizontal Pod Autoscaling](https://www.youtube.com/watch?v=aKBG6yJ3sMg).
+Please read this blog post to learn how to scale a WebLogic cluster, based on WebLogic metrics provided by the Monitoring Exporter, using the Kubernetes Horizontal Pod Autoscaler (HPA). We will use the Prometheus Adapter to gather the names of the available metrics from Prometheus at regular intervals. A custom configuration of the adapter will expose only metrics that follow specific formats. [Horizontal Pod Autoscaler (HPA) using WebLogic Exporter Metrics](https://blogs.oracle.com/weblogicserver/post/horizontal-pod-autoscaler-hpausing-weblogic-exporter-metrics). See this corresponding video for a demonstration of the blog post in action. [WebLogic Kubernetes Operator support for Kubernetes Horizontal Pod Autoscaling](https://www.youtube.com/watch?v=aKBG6yJ3sMg).
 
 #### Using a Prometheus alert action to call the operator's REST scale API
 In addition to using the WebLogic Diagnostic Framework for automatic scaling of a dynamic cluster,

documentation/site/content/managing-domains/domain-on-pv/usage.md

@@ -17,7 +17,7 @@ Deploy the operator and ensure that it is monitoring the desired namespace for y
 
 ### Configuration
 
-Beginning with operator version 4.1.0, you can provide a section, `domain.spec.configuraiton.initializeDomainOnPV`, to initialize a WebLogic domain on a persistent volume when it is first deployed.
+Beginning with operator version 4.1.0, you can provide a section, `domain.spec.configuration.initializeDomainOnPV`, to initialize a WebLogic domain on a persistent volume when it is first deployed.
 This is a _one time only_ initialization. After the domain is created, subsequent updates to this section in the domain resource YAML file will not recreate or update the
 WebLogic domain.
 

documentation/site/content/managing-domains/major-weblogic-version-upgrade/upgrade-14210.md

@@ -225,7 +225,7 @@ STB.cleartextSchemaPassword = <TODO: provides the clear text password>
 STB.dbaUserName = <TODO: provide dba user name, e.g. sys as sysdba>
 STB.cleartextDbaPassword = <TODO: provides clear text dba password>
 
-# This secion is not needed for pure JRF domain.
+# This section is not needed for pure JRF domain.
 
 # The next section contains the information for performing a schema
 # upgrade on Oracle WebLogicServer, as described in the Upgrade

documentation/site/content/managing-operators/overview.md

@@ -25,7 +25,7 @@ A completely installed and running WebLogic Kubernetes Operator environment incl
 - A pair of Kubernetes custom resource definitions (CRD) for domain and cluster resource that, when installed,
   enables the Kubernetes API server and the operator to monitor and manage their resource instances.
 - One or more operator runtimes, each deployed to a different namespace, that monitor Kubernetes namespaces for domain resources.
-- A WebLogic domain resource conversion webhook that runs in a single namespacre in the Kubernetes cluster, that is shared by the operator runtimes, and that handles the automatic conversion of older versions of the domain resource.
+- A WebLogic domain resource conversion webhook that runs in a single namespace in the Kubernetes cluster, that is shared by the operator runtimes, and that handles the automatic conversion of older versions of the domain resource.
 - Each operator is associated with a local Kubernetes service account for security purposes. The service account is deployed to the same namespace as the operator.
 
 When an operator runtime detects a domain,

documentation/site/content/managing-operators/preparation.md

@@ -321,7 +321,7 @@ helm install weblogic-operator weblogic-operator/weblogic-operator --namespace w
 ```
 
 {{% notice note %}}
-Since this combination of options omits installing the webhook deployment, customers must use the `v9` schema version for Domain resources and manually uprade any `v8` resources from the 3.x version of the operator.
+Since this combination of options omits installing the webhook deployment, customers must use the `v9` schema version for Domain resources and manually upgrade any `v8` resources from the 3.x version of the operator.
 {{% /notice %}}
 
 #### Choose a domain namespace selection strategy