Owls 89504 - Common mounts MII sample generator changes, image creation scripts and draft documentation (#2380)

* MII sample generator changes for common mounts, image creation scripts and initial draft of common mounts documentation.

Co-authored-by: Tom Barnes <[email protected]>
Co-authored-by: Rosemary Marano <[email protected]>

Author: 3 people

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

@@ -19,12 +19,12 @@ Note that you can use different domain home types for different domains; there's
 | --- | --- | --- |
 | 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. |
-| The domain is long-lived, so you can mutate the configuration or deploy new applications using the Administration Console or WLST. You can also mutate the configuration using configuration overrides. | If you want to mutate the domain home configuration, then you can apply configuration overrides or create a new image. If you want to deploy application updates, then you must create a new image. | If you want to mutate the domain home configuration, then you can override it with additional model files supplied in a ConfigMap or you can supply a new image. If you want to deploy application updates, then you must create a new image.  |
-| You can use configuration overrides to mutate the domain configuration, but there are [limitations]({{< relref "/userguide/managing-domains/configoverrides/_index.md#unsupported-overrides" >}}). | You can use configuration overrides to mutate the domain configuration, but there are [limitations]({{< relref "/userguide/managing-domains/configoverrides/_index.md#unsupported-overrides" >}}). | You can deploy model files to a ConfigMap to mutate the domain, and may not need to restart the entire domain for the change to take effect. Instead, you can initiate a rolling upgrade, which restarts your WebLogic Server instance Pods one at a time. Also, 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 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 only be changed when servers are starting. |  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 only be changed when servers are starting. You should not use the Administration Console or WLST for these domains as changes are ephemeral and will be lost when servers 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 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 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 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.  |
+| 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. |
 | 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.|
+| 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.|
 | 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/staging/content/userguide/managing-domains/domain-lifecycle/restarting.md

@@ -64,10 +64,7 @@ Otherwise, use of a new image that does not have compatible encryption keys or a
 
 * If you create a new image with the same name, then you must manually initiate either a full domain restart or rolling restart for pods to run with the new image. To initiate a full restart, see [Full domain restarts]({{< relref "/userguide/managing-domains/domain-lifecycle/startup/_index.md#full-domain-restarts">}}). To initiate a rolling restart, change the value of your Domain `restartVersion` field.  See [Restarting servers]({{< relref "/userguide/managing-domains/domain-lifecycle/startup/_index.md#restarting-servers" >}}) and [Rolling restarts]({{< relref "/userguide/managing-domains/domain-lifecycle/startup/_index.md#rolling-restarts" >}}).
 
-* If you are supplying updated models or Secrets for a running domain, and you want the configuration updates to take effect using a rolling restart, then do one of the following:
-  * Supply a new value for the `image` field in the Domain or any of the other [fields affecting WebLogic Server instance Pod generation]({{< relref "/userguide/managing-domains/domain-lifecycle/startup/_index.md#fields-that-cause-servers-to-be-restarted" >}}).
-  * Change the Domain `restartVersion` field. This will cause the operator to restart all running servers and, prior to the restarts, the operator will introspect any new configuration.
-  * Change the Domain `introspectVersion` field. This will cause the operator to introspect any new configuration and, if needed, restart servers to use that new configuration.
+* If you are supplying updated models or Secrets for a running domain, then see [Runtime updates]({{< relref "/userguide/managing-domains/model-in-image/runtime-updates.md" >}}).
 
 ##### Domain in PV
 

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

@@ -256,6 +256,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`
 * `containerSecurityContext`
 * `domainHome`
 * `domainHomeInImage`