Rename common mounts to auxiliary images (#2444)

* Rename common mounts to auxiliary images

Author: rjeberhard

documentation/2.6/content/samples/simple/domains/model-in-image/_index.md

@@ -865,7 +865,7 @@ Copy the following to a file called `/tmp/mii-sample/mii-initial.yaml` or simila
       serverPod:
         # Optional new or overridden environment variables for the domain's pods
         # - This sample uses CUSTOM_DOMAIN_NAME in its image model file
-        #   to set the Weblogic domain name
+        #   to set the WebLogic domain name
         env:
         - name: CUSTOM_DOMAIN_NAME
           value: "domain1"
@@ -990,7 +990,7 @@ Copy the following to a file called `/tmp/mii-sample/mii-initial.yaml` or simila
     serverPod:
       # Optional new or overridden environment variables for the domain's pods
       # - This sample uses CUSTOM_DOMAIN_NAME in its image model file
-      #   to set the Weblogic domain name
+      #   to set the WebLogic domain name
       env:
       - name: CUSTOM_DOMAIN_NAME
         value: "domain1"

documentation/3.0/content/samples/simple/domains/model-in-image/initial.md

@@ -442,7 +442,7 @@ Copy the following to a file called `/tmp/mii-sample/mii-initial.yaml` or simila
       serverPod:
         # Optional new or overridden environment variables for the domain's pods
         # - This sample uses CUSTOM_DOMAIN_NAME in its image model file
-        #   to set the Weblogic domain name
+        #   to set the WebLogic domain name
         env:
         - name: CUSTOM_DOMAIN_NAME
           value: "domain1"
@@ -564,7 +564,7 @@ Copy the following to a file called `/tmp/mii-sample/mii-initial.yaml` or simila
     serverPod:
       # Optional new or overridden environment variables for the domain's pods
       # - This sample uses CUSTOM_DOMAIN_NAME in its image model file
-      #   to set the Weblogic domain name
+      #   to set the WebLogic domain name
       env:
       - name: CUSTOM_DOMAIN_NAME
         value: "domain1"

documentation/3.1/content/samples/simple/domains/model-in-image/initial.md

@@ -442,7 +442,7 @@ Copy the following to a file called `/tmp/mii-sample/mii-initial.yaml` or simila
       serverPod:
         # Optional new or overridden environment variables for the domain's pods
         # - This sample uses CUSTOM_DOMAIN_NAME in its image model file
-        #   to set the Weblogic domain name
+        #   to set the WebLogic domain name
         env:
         - name: CUSTOM_DOMAIN_NAME
           value: "domain1"
@@ -564,7 +564,7 @@ Copy the following to a file called `/tmp/mii-sample/mii-initial.yaml` or simila
     serverPod:
       # Optional new or overridden environment variables for the domain's pods
       # - This sample uses CUSTOM_DOMAIN_NAME in its image model file
-      #   to set the Weblogic domain name
+      #   to set the WebLogic domain name
       env:
       - name: CUSTOM_DOMAIN_NAME
         value: "domain1"

documentation/3.1/content/samples/simple/tanzu-kubernetes-service/_index.md

@@ -469,7 +469,7 @@ Copy the following to a file called `/tmp/mii-sample/mii-initial.yaml` or simila
       serverPod:
         # Optional new or overridden environment variables for the domain's pods
         # - This sample uses CUSTOM_DOMAIN_NAME in its image model file
-        #   to set the Weblogic domain name
+        #   to set the WebLogic domain name
         env:
         - name: CUSTOM_DOMAIN_NAME
           value: "domain1"

documentation/3.2/content/samples/simple/domains/model-in-image/initial.md

@@ -395,18 +395,18 @@ Run the following `kubectl` commands to deploy the required secrets:
   $ kubectl -n sample-domain1-ns create secret generic \
     sample-domain1-weblogic-credentials \
      --from-literal=username=weblogic --from-literal=password=welcome1
-    ```
-    ```shell
+  ```
+  ```shell
   $ kubectl -n sample-domain1-ns label  secret \
     sample-domain1-weblogic-credentials \
     weblogic.domainUID=sample-domain1
-    ```
-    ```shell
+  ```
+  ```shell
   $ kubectl -n sample-domain1-ns create secret generic \
     sample-domain1-runtime-encryption-secret \
      --from-literal=password=my_runtime_password
-    ```
-    ```shell
+  ```
+  ```shell
   $ kubectl -n sample-domain1-ns label  secret \
     sample-domain1-runtime-encryption-secret \
     weblogic.domainUID=sample-domain1
@@ -444,18 +444,18 @@ Run the following `kubectl` commands to deploy the required secrets:
      --from-literal=rcu_prefix=FMW1 \
      --from-literal=rcu_schema_password=Oradoc_db1 \
      --from-literal=rcu_db_conn_string=oracle-db.default.svc.cluster.local:1521/devpdb.k8s
-    ```
-    ```shell
+  ```
+  ```shell
   $ kubectl -n sample-domain1-ns label  secret \
     sample-domain1-rcu-access \
     weblogic.domainUID=sample-domain1
-    ```
-    ```shell
+  ```
+  ```shell
   $ kubectl -n sample-domain1-ns create secret generic \
     sample-domain1-opss-wallet-password-secret \
      --from-literal=walletPassword=welcome1
-    ```
-    ```shell
+  ```
+  ```shell
   $ kubectl -n sample-domain1-ns label  secret \
     sample-domain1-opss-wallet-password-secret \
     weblogic.domainUID=sample-domain1
@@ -526,7 +526,7 @@ Copy the following to a file called `/tmp/mii-sample/mii-initial.yaml` or simila
       serverPod:
         # Optional new or overridden environment variables for the domain's pods
         # - This sample uses CUSTOM_DOMAIN_NAME in its image model file
-        #   to set the Weblogic domain name
+        #   to set the WebLogic domain name
         env:
         - name: CUSTOM_DOMAIN_NAME
           value: "domain1"
@@ -648,7 +648,7 @@ Copy the following to a file called `/tmp/mii-sample/mii-initial.yaml` or simila
     serverPod:
       # Optional new or overridden environment variables for the domain's pods
       # - This sample uses CUSTOM_DOMAIN_NAME in its image model file
-      #   to set the Weblogic domain name
+      #   to set the WebLogic domain name
       env:
       - name: CUSTOM_DOMAIN_NAME
         value: "domain1"

documentation/3.2/content/samples/simple/tanzu-kubernetes-service/_index.md

@@ -499,7 +499,7 @@ Copy the following to a file called `/tmp/mii-sample/mii-initial.yaml` or simila
       serverPod:
         # Optional new or overridden environment variables for the domain's pods
         # - This sample uses CUSTOM_DOMAIN_NAME in its image model file
-        #   to set the Weblogic domain name
+        #   to set the WebLogic domain name
         env:
         - name: CUSTOM_DOMAIN_NAME
           value: "domain1"

documentation/3.2/content/userguide/managing-domains/choosing-a-model/_index.md

@@ -20,11 +20,11 @@ When using the operator to start WebLogic Server instances from a domain, you ha
  - **[Model in Image]({{< relref "/samples/simple/domains/model-in-image/_index.md" >}})**:
    - Supply a WebLogic installation in an image and supply WebLogic configuration in one of three ways:
      - As WebLogic Deployment Tool (WDT) model YAML file layered on the WebLogic installation image.
-     - As WDT model YAML file supplied in separate [common mount images]({{< relref "/userguide/managing-domains/model-in-image/common-mounts.md" >}}).
+     - As WDT model YAML file supplied in separate [auxiliary images]({{< relref "/userguide/managing-domains/model-in-image/auxiliary-images.md" >}}).
      - As WDT model YAML file in a Kubernetes ConfigMap.
    - Supply WebLogic applications in one of two ways:
      - Layered on the installation image.
-     - In common mount images.
+     - In auxiliary images.
    - Mutate WebLogic configuration by supplying a new image and rolling, or [model updates]({{< relref "/userguide/managing-domains/model-in-image/runtime-updates.md" >}}) supplied in a Kubernetes ConfigMap.
 
 Note that you can use different domain home types for different domains; there's no restriction on having domains with different domain home types in the same Kubernetes cluster or namespace.
@@ -35,12 +35,12 @@ There are advantages for each domain home source type where Model in Image is th
 | --- | --- | --- |
 | Lets you use the same standard WebLogic Server image for every server in every domain. | Requires a different image for each domain, but all servers in that domain use the same image. | Different domains can use the same image, but require different domainUID and may have different configuration.  |
 | No state is kept in images making the containers created from these images completely throw away (cattle not pets). | Runtime state should not be kept in the images, but applications and configuration are. | Runtime state should not be kept in the images.  Application and configuration may be. |
-| You can deploy new applications using the Administration Console or WLST. | If you want to deploy application updates, then you must create a new image. | If you want to deploy application updates, then you must create a new image, which optionally can be a [common mounts image]({{< relref "/userguide/managing-domains/model-in-image/common-mounts.md" >}}) that doesn't include a WebLogic installation. |
+| You can deploy new applications using the Administration Console or WLST. | If you want to deploy application updates, then you must create a new image. | If you want to deploy application updates, then you must create a new image, which optionally can be an [auxiliary image]({{< relref "/userguide/managing-domains/model-in-image/auxiliary-images.md" >}}) that doesn't include a WebLogic installation. |
 | You can use configuration overrides to mutate the domain configuration before it is deployed, but there are [limitations]({{< relref "/userguide/managing-domains/configoverrides/_index.md#unsupported-overrides" >}}). | Same as Domain in PV. | You can deploy model files to a ConfigMap to mutate the domain before it is deployed. The model file syntax is far simpler and less error prone than the configuration override syntax, and, unlike configuration overrides, allows you to directly add data sources and JMS modules. |
 | You can change WebLogic domain configuration at runtime using the Administration Console or WLST. You can also change configuration overrides and [distribute the new overrides]({{< relref "/userguide/managing-domains/domain-lifecycle/introspection.md#distributing-changes-to-configuration-overrides" >}}) to running servers; however, non-dynamic configuration attributes can be changed only when servers are starting and some changes may require a full domain restart. |  You also can change configuration overrides and [distribute the new overrides]({{< relref "/userguide/managing-domains/domain-lifecycle/introspection.md#distributing-changes-to-configuration-overrides" >}}) to running servers; however, non-dynamic configuration attributes can be changed only when servers are starting and some changes may require a full domain restart. You should not use the Administration Console or WLST for these domains as changes are ephemeral and will be lost when servers restart. |  You can change configuration at runtime using model YAML file snippets supplied in [runtime updates]({{< relref "/userguide/managing-domains/model-in-image/runtime-updates.md" >}}) (which are substantially easier to specify than configuration overrides); however, non-dynamic configuration attributes will change only when servers are restarted (rolled) and some changes may require a full domain restart. You should not use the Administration Console or WLST for these domains as changes are ephemeral and will be lost when servers restart. |
 | Logs are automatically placed on persistent storage and sent to the pod's stdout.  | Logs are kept in the containers and sent to the pod's log (`stdout`) by default. To change the log location, you can set the Domain `logHomeEnabled` to true and configure the desired directory using `logHome`. | Same as Domain in Image.  |
-| Patches can be applied by simply changing the image and rolling the domain.  | To apply patches, you must update the domain-specific image and then restart or roll the domain depending on the nature of the patch.  | Same as Domain in PV when using dedicated [common mounts images]({{< relref "/userguide/managing-domains/model-in-image/common-mounts.md" >}}) to supply model artifacts; same as Domain in Image otherwise. |
+| Patches can be applied by simply changing the image and rolling the domain.  | To apply patches, you must update the domain-specific image and then restart or roll the domain depending on the nature of the patch.  | Same as Domain in PV when using dedicated [auxiliary images]({{< relref "/userguide/managing-domains/model-in-image/auxiliary-images.md" >}}) to supply model artifacts; same as Domain in Image otherwise. |
 | Many cloud providers do not provide persistent volumes that are shared across availability zones, so you may not be able to use a single persistent volume.  You may need to use some kind of volume replication technology or a clustered file system. | Provided you do not store and state in containers, you do not have to worry about volume replication across availability zones because each pod has its own copy of the domain.  WebLogic replication will handle propagation of any online configuration changes.  | Same as Domain in Image. |
 | CI/CD pipelines may be more complicated because you would need to run WLST against the live domain directory to effect changes.  | CI/CD pipelines are simpler because you can create the whole domain in the image and don't have to worry about a persistent copy of the domain.  | CI/CD pipelines are even simpler because you don't need to generate a domain home. The operator will create a domain home for you based on the model that you supply. |
-| There are fewer images to manage and store, which could provide significant storage and network savings.  |  There are more images to manage and store in this approach. | Same as Domain in Image unless you use the [common mounts]({{< relref "/userguide/managing-domains/model-in-image/common-mounts.md" >}}) approach. With common mounts, you can use a single image to distribute your WebLogic installation (similar to Domain on PV), plus one or more specific dedicated images that contain your WebLogic configuration and applications.|
+| There are fewer images to manage and store, which could provide significant storage and network savings.  |  There are more images to manage and store in this approach. | Same as Domain in Image unless you use the [auxiliary images]({{< relref "/userguide/managing-domains/model-in-image/auxiliary-images.md" >}}) approach. With auxiliary images, you can use a single image to distribute your WebLogic installation (similar to Domain on PV), plus one or more specific dedicated images that contain your WebLogic configuration and applications.|
 | You may be able to use standard Oracle-provided images or, at least, a very small number of self-built images, for example, with patches installed. | You may need to do more work to set up processes to build and maintain your images. | Same as Domain in Image.|

documentation/3.2/content/userguide/managing-domains/domain-lifecycle/liveness-readiness-probe-customization.md

@@ -56,7 +56,7 @@ The following operator-populated environment variables are available for use in
 
 `ORACLE_HOME` or `MW_HOME`: The Oracle Fusion Middleware software location as a file system path within the container.
 
-`WL_HOME`: The Weblogic Server installation location as a file system path within the container. 
+`WL_HOME`: The WebLogic Server installation location as a file system path within the container. 
 
 `DOMAIN_HOME`: The domain home location as a file system path within the container.
 

documentation/3.2/content/userguide/managing-domains/domain-lifecycle/startup.md

@@ -274,8 +274,8 @@ The operator does rolling restarts of clustered servers so that service is maint
 
 The operator will restart servers when any of the follow fields on the Domain that affect the WebLogic Server instance Pod generation are changed:
 
-* `commonMounts`
-* `commonMountVolumes`
+* `auxiliaryImages`
+* `auxiliaryImageVolumes`
 * `containerSecurityContext`
 * `domainHome`
 * `domainHomeInImage`