Merge branch 'rm/change-to-Domain-on-PV' into 'main'

Change to Domain on PV

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

Author: rjeberhard

documentation/4.1/content/_index.md

@@ -11,8 +11,8 @@ You can:
 * Supply WebLogic domain configuration using:
   * _Model in Image_: Includes [WebLogic Deploy Tooling](https://github.com/oracle/weblogic-deploy-tooling) models and archives in a container image.
   * _Domain in Image_: Includes a WebLogic domain home in a container image.
-     * **NOTE**: The Domain in Image [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain in PV or Model in Image, depending on your needs.
-  * _Domain in PV_: Locates WebLogic domain homes in a Kubernetes PersistentVolume (PV). This PV can reside in an NFS file system or other Kubernetes volume types.
+     * **NOTE**: The Domain in Image [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain on PV or Model in Image, depending on your needs.
+  * _Domain on PV_: Locates WebLogic domain homes in a Kubernetes PersistentVolume (PV). This PV can reside in an NFS file system or other Kubernetes volume types.
 * Configure deployment of WebLogic domains as Kubernetes resources (using Kubernetes custom resource definitions).
 * Override certain aspects of the WebLogic domain configuration; for example, use a different database password for different deployments.
 * Start and stop servers and clusters in the domain based on declarative startup parameters and desired states.

documentation/4.1/content/base-images/custom-images.md

@@ -34,7 +34,7 @@ Finally, you can use the WIT `inspect` command to [inspect images]({{< relref "/
   - WIT [`create`](https://oracle.github.io/weblogic-image-tool/userguide/tools/create-image/) command:
 
     - Creates a new WebLogic image from a base OS image.
-    - Can be used for all [domain home source types]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) (Domain in Image, Model in Image, and Domain in PV).
+    - Can be used for all [domain home source types]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) (Domain in Image, Model in Image, and Domain on PV).
     - Optionally, includes a WebLogic Deploy Tooling (WDT) [installation](https://oracle.github.io/weblogic-deploy-tooling/userguide/install/) and model files in the image
       (for Model in Image domains).
       See also, [Create a custom image with your model inside the image](#create-a-custom-image-with-your-model-inside-the-image).
@@ -279,7 +279,7 @@ image that is meant for updating an already running domain, then see
 [Apply patched images to a running domain]({{< relref "/base-images/patch-images#apply-patched-images-to-a-running-domain" >}}).
 
 **NOTE**: The Domain in Image [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) is
-deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain in PV or Model in Image, depending on your needs.
+deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain on PV or Model in Image, depending on your needs.
 
 For Domain in Image domains,
 you must create an image with the WebLogic domain inside the image.

documentation/4.1/content/base-images/patch-images.md

@@ -13,7 +13,7 @@ The procedure for the operator to update the running domain differs depending on
 [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}).
 See the following corresponding sections:
 
-- [Domain in PV](#domain-in-pv)
+- [Domain on PV](#domain-on-pv)
 - [Model in Image with auxiliary images](#model-in-image-with-auxiliary-images)
 - [Model in Image without auxiliary images](#model-in-image-without-auxiliary-images)
 - [Domain in Image](#domain-in-image)
@@ -22,20 +22,20 @@ For a broader description of managing the evolution and mutation
 of container images to run WebLogic Server in Kubernetes,
 see [CI/CD]({{< relref "/managing-domains/cicd/_index.md" >}}).
 
-#### Domain in PV
+#### Domain on PV
 
 {{% notice warning %}}
-Oracle strongly recommends strictly limiting access to Domain in PV domain home files.
+Oracle strongly recommends strictly limiting access to Domain on PV domain home files.
 A WebLogic domain home has sensitive information
 including credentials that are used to access external resources
 (for example, a data source password),
 and decryption keys
 (for example, the `DOMAIN_HOME/security/SerializedSystemIni.dat` domain secret file).
 {{% /notice %}}
 
-For Domain in PV domains,
+For Domain on PV domains,
 the container image contains only the JDK and WebLogic Server binaries,
-and its domain home is located in a Persistent Volume (PV)
+and its domain home is located on a Persistent Volume (PV)
 where the domain home is generated by the user.
 
 For this domain home source type, you can create your own patched images using the steps
@@ -95,7 +95,7 @@ of the WebLogic domain to update the Oracle Home of the servers.
 
 #### Domain in Image
 
-**NOTE**: The Domain in Image [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain in PV or Model in Image, depending on your needs.
+**NOTE**: The Domain in Image [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain on PV or Model in Image, depending on your needs.
 
 If you need to update the image for a running Domain in Image domain,
 then use the WIT [`rebase`](https://oracle.github.io/weblogic-image-tool/userguide/tools/rebase-image/)

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

@@ -55,7 +55,7 @@ may have different images under the same tag in their individual, local containe
 The simplest solution is to set `imagePullPolicy` to `Always`; however, the better solution would be to design your development
 pipeline to generate new container image tags on every build and to never reuse an existing tag.
 
-#### Domain in PV
+#### Domain on PV
 
 ##### Completely replacing the domain directory
 

documentation/4.1/content/faq/security-validation.md

@@ -16,7 +16,7 @@ WebLogic Server has a new, important feature to ensure and help you secure your
 
 Warnings may be at the level of the JDK, or that SSL is not enabled. Some warnings may recommend updating your WebLogic configuration. You can make the recommended configuration changes using an approach that depends on your [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}):
 
-- For Domain in PV, use the WebLogic Scripting Tool (WLST), WebLogic Server Administration Console, WebLogic Deploy Tooling (WDT), or [configuration overrides]({{< relref "/managing-domains/configoverrides/_index.md" >}}).
+- For Domain on PV, use the WebLogic Scripting Tool (WLST), WebLogic Server Administration Console, WebLogic Deploy Tooling (WDT), or [configuration overrides]({{< relref "/managing-domains/configoverrides/_index.md" >}}).
 
 - For Domain in Image, create a new image with the recommended changes or use [configuration overrides]({{< relref "/managing-domains/configoverrides/_index.md" >}}).
 

documentation/4.1/content/introduction/platforms/environments.md

@@ -121,9 +121,9 @@ referenced in the [Overview](#overview)). In this environment, it is the custome
 AKS support and limitations:
 
 * Operator v3.4.4 is certified for use on AKS with Kubernetes 1.24.3+.
-* All three [domain home source types]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) are supported (Domain in Image, Model in Image, and Domain in PV).
-   * **NOTE**: The Domain in Image [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain in PV or Model in Image, depending on your needs.
-* For Domain in PV, we support Azure Files volumes accessed through
+* All three [domain home source types]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) are supported (Domain in Image, Model in Image, and Domain on PV).
+   * **NOTE**: The Domain in Image [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain on PV or Model in Image, depending on your needs.
+* For Domain on PV, we support Azure Files volumes accessed through
   a persistent volume claim; see [here](https://docs.microsoft.com/en-us/azure/aks/azure-files-volume).
 * Azure Load Balancers are supported when provisioned using a Kubernetes Service of `type=LoadBalancer`.
 * Oracle databases running in Oracle Cloud Infrastructure are supported for Fusion Middleware
@@ -155,7 +155,7 @@ The WebLogic Kubernetes Operator and Oracle WebLogic Server are fully supported
 
 TKG support and limitations:
 
-* Both Domain in Image and Model in Image domain home source types are supported. Domain in PV is not supported.
+* Both Domain in Image and Model in Image domain home source types are supported. Domain on PV is not supported.
 * VSphere CSI driver supports only volumes with Read-Write-Once policy. This does not allow writing stores on PV.
   * For applications requiring HA, use JMS and JTA stores in the database.
 * The ingress used for certification is NGINX, with MetalLB load balancer.

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

@@ -13,7 +13,7 @@ This document describes the domain home source types for deploying a domain, and
 
 When using the operator to start WebLogic Server instances from a domain, you have the choice of the following WebLogic domain home source types:
 
-{{% notice note %}}The **Domain in Image** domain home source type is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain in PV or Model in Image, depending on your needs.
+{{% notice note %}}The **Domain in Image** domain home source type is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain on PV or Model in Image, depending on your needs.
 {{% /notice %}}
 
  - **[Model in Image]({{< relref "/samples/domains/model-in-image/_index.md" >}})**:
@@ -39,10 +39,10 @@ When using the operator to start WebLogic Server instances from a domain, you ha
      or by [configuration overrides]({{< relref "/managing-domains/configoverrides/_index.md" >}})
      supplied in a Kubernetes ConfigMap.
 
- - **[Domain in PV]({{< relref "/samples/domains/domain-home-on-pv/_index.md" >}})**:
+ - **[Domain on PV]({{< relref "/samples/domains/domain-home-on-pv/_index.md" >}})**:
    - Set the domain resource `domain.spec.domainHomeSourceType` attribute to `PersistentVolume`.
-   - Supply a WebLogic installation in an image and supply a WebLogic configuration as a domain home in a persistent volume.
-   - Supply WebLogic applications in the persistent volume.
+   - Supply a WebLogic installation in an image and supply a WebLogic configuration as a domain home on a persistent volume.
+   - Supply WebLogic applications on the persistent volume.
    - Mutate the WebLogic configuration using WLST,
      the WebLogic Server Administration Console,
      or [configuration overrides]({{< relref "/managing-domains/configoverrides/_index.md" >}})
@@ -52,15 +52,15 @@ Note that you can use different domain home types for different domains; there's
 
 There are advantages for each domain home source type where Model in Image is the most popular choice, but sometimes there are also technical limitations of various cloud providers that may make one type better suited to your needs. The following table compares the types:
 
-| Domain in PV | Domain in Image | Model in Image |
+| Domain on PV | Domain in Image | Model in Image |
 | --- | --- | --- |
 | 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 an [auxiliary image]({{< relref "/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 "/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 use configuration overrides to mutate the domain configuration before it is deployed, but there are [limitations]({{< relref "/managing-domains/configoverrides/_index.md#unsupported-overrides" >}}). | Same as Domain on 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 "/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 "/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 "/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 [auxiliary images]({{< relref "/managing-domains/model-in-image/auxiliary-images.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 on PV when using dedicated [auxiliary images]({{< relref "/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 [auxiliary images]({{< relref "/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 in PV), plus one or more specific dedicated images that contain your WebLogic configuration and applications.|
@@ -82,7 +82,7 @@ There are advantages for each domain home source type where Model in Image is th
 * Domain in Image domains:
   * [Create a custom image with your domain inside the image]({{< relref "/base-images/custom-images#create-a-custom-image-with-your-domain-inside-the-image" >}})
 
-* Domain in Persistent Volume (PV) domains:
+* Domain on Persistent Volume (PV) domains:
   * [Understand Oracle Container Registry images]({{< relref "/base-images/ocr-images#understand-oracle-container-registry-images" >}})
   * [Obtain images from the Oracle Container Registry]({{< relref "/base-images/ocr-images#obtain-images-from-the-oracle-container-registry" >}})
   * [Create a custom image with patches applied]({{< relref "/base-images/custom-images#create-a-custom-image-with-patches-applied" >}})

documentation/4.1/content/managing-domains/cicd/_index.md

@@ -50,13 +50,13 @@ but the shortest distances, almost always requires using a single database
 server to consolidate and replicate data (DataGuard).
 
 There are three common approaches on how to structure these components:
- * The first, "domain on a persistent volume" or Domain in PV,
+ * The first, "domain on a persistent volume" or Domain on PV,
    places the JDK and WebLogic binaries
    in the image, but the domain home is kept on a separate persistent storage
    outside of the image.
  * The second, Domain in Image,
    puts the JDK, WebLogic Server binaries,
-   and the domain home all in the image. **NOTE**: The Domain in Image [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain in PV or Model in Image, depending on your needs.
+   and the domain home all in the image. **NOTE**: The Domain in Image [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain on PV or Model in Image, depending on your needs.
  * The third approach, Model in Image, puts the JDK, WebLogic Server binaries, and a domain model
    in the image, and generates the domain home at runtime
    from the domain model.