oracle
diff --git a/‎docs-source/content/quickstart/prepare.md‎
Lines changed: 5 additions & 0 deletions b/‎docs-source/content/quickstart/prepare.md‎
Lines changed: 5 additions & 0 deletions
diff --git a/‎docs-source/content/samples/simple/domains/model-in-image/_index.md‎
Lines changed: 1508 additions & 290 deletions b/‎docs-source/content/samples/simple/domains/model-in-image/_index.md‎
Lines changed: 1508 additions & 290 deletions
diff --git a/‎docs-source/content/userguide/managing-domains/choosing-a-model/_index.md‎
Lines changed: 16 additions & 16 deletions b/‎docs-source/content/userguide/managing-domains/choosing-a-model/_index.md‎
Lines changed: 16 additions & 16 deletions
diff --git a/‎docs-source/content/userguide/managing-domains/domain-resource.md‎
Lines changed: 1 addition & 1 deletion b/‎docs-source/content/userguide/managing-domains/domain-resource.md‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎docs-source/content/userguide/managing-domains/model-in-image/debugging.md‎
Lines changed: 6 additions & 2 deletions b/‎docs-source/content/userguide/managing-domains/model-in-image/debugging.md‎
Lines changed: 6 additions & 2 deletions
diff --git a/‎docs-source/content/userguide/managing-domains/model-in-image/model-files.md‎
Lines changed: 20 additions & 11 deletions b/‎docs-source/content/userguide/managing-domains/model-in-image/model-files.md‎
Lines changed: 20 additions & 11 deletions
@@ -31,3 +31,8 @@ weight: 5
         --set "kubernetes.namespaces={traefik,sample-domain1-ns}" \
         --wait
     ```
+
+{{% notice note %}}
+If you have reached this point while following the "Model in image" sample, please
+stop here and return to the [Model in image sample instructions]({{< relref "/samples/simple/domains/model-in-image/_index.md#resume" >}}).
+{{% /notice %}}
@@ -5,25 +5,25 @@ weight = 1
 pre = "<b> </b>"
 +++
 
-When using the operator to deploy a WebLogic domain, you have the choice of the following WebLogic domain home source types:
+When using the operator to deploy a WebLogic domain, you have the choice of the following WebLogic domain home source types: 
 
- - **Domain in PV**: Supply your domain home configuration in a persistent volume.
- - **Domain in Image**: Supply your domain home in a Docker image.
- - **Model in Image**: Supply a WebLogic Deployment Tool model file in a Docker image.
+ - **Domain in PV**: Supply your domain home configuration in a persistent volume. 
+ - **Domain in Image**: Supply your domain home in a Docker image. 
+ - **Model in Image**: Supply a WebLogic Deployment Tool model file in a Docker image. 
 
-There are advantages for each domain home source type, but sometimes there are technical limitations of various cloud providers that may make one type better suited to your needs.
+There are advantages for each domain home source type, but sometimes there are technical limitations of various cloud providers that may make one type better suited to your needs. 
 
-Note that you can use different domain home types for different domains; there's no restriction on having domains with different domain home types deployed to the same Kubernetes cluster or namespace.
+Note that you can use different domain home types for different domains; there's no restriction on having domains with different domain home types deployed to the same Kubernetes cluster or namespace. 
 
 | Domain in PV | Domain in Image | Model in Image |
 | --- | --- | --- |
-| Lets you use the same standard read-only Docker image for every server in every domain. | Requires a different image for each domain, but all servers in that domain use the same image. | Same as Domain in Image. |
-| No state is kept in Docker images making them completely throw away (cattle not pets). | Runtime state should not be kept in the images, but applications and configuration are. | Same as Domain in Image.|
-| The domain is long-lived, so you can mutate the configuration or deploy new applications using standard methods (Administration Console, WLST, and such). 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 config map 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 at runtime, but this requires first shutting down the entire domain, and then restarting it for the change to take effect. | You can use configuration overrides to mutate the domain home at runtime, but this requires first shutting down the entire domain, and then restarting it for the change to take effect. | You can deploy model files to a config map to mutate the domain at runtime, and do 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 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. |
-| Logs are automatically placed on persistent storage.  | Logs are kept in the images and sent to the pod's log (`stdout`) by default. To change their location, you can set the domain resource `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 create a new domain-specific image and then roll the domain.  | Same as Domain in Image. |
-| 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. | 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. If you are using a JRF domain, then the domain's RCU wallet must be extracted from the domain and supplied to the failed over or restarted domain. | Same as Domain in Image. |
-| CI/CD pipelines may be more complicated because you would probably 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 less 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.|
-| 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.|
+| Lets you use the same standard read-only Docker 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 Docker images making them 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 standard methods (Administration Console, WLST, and such). 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 config map 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 at runtime, but this requires first shutting down the entire domain, and then restarting it for the change to take effect. | You can use configuration overrides to mutate the domain home at runtime, but this requires first shutting down the entire domain, and then restarting it for the change to take effect. 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 model files to a config map to mutate the domain at runtime, 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 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 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 images and sent to the pod's log (`stdout`) by default. To change their location, you can set the domain resource `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.  |
+| 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 probably 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 less 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.| 
+| 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.| 
@@ -101,7 +101,7 @@ Elements related to specifying and overriding WebLogic domain configuration:
   * `runtimeEncryptionSecret`: Required. Expected field is `password`. This is used by Model in Image to encrypt data while the data is passed from the introspector job to WebLogic pods. The password can be arbitrary: the only requirement is that it must stay the same for the life of a domain resource. If a domain resource is deleted then redeployed, it's fine to change the password during the interim.
   * `wdtEncryptionSecret`: Optional. Rarely used. See [Model in Image]({{< relref "/userguide/managing-domains/model-in-image/_index.md" >}}) for details.
 
-* These elements are under `configuration.opss`, and only apply if the `domainHomeSourceType` is `FromModel` and the `domainType` is `JRF`. For details, see [Reusing an RCU database]({{< relref "/userguide/managing-domains/model-in-image/reusing-rcu.md" >}}).
+* These elements are under `configuration.opss`, and only apply if the `domainHomeSourceType` is `FromModel` and the `domainType` is `JRF`. 
 
   * `walletPasswordSecret`: The expected secret field is `walletPassword`. Used to encrypt/decrypt the wallet that's used for accessing the domain's entries in its RCU database.
   * `walletFileSecret`: Optional. The expected secret field is `walletFile`. Use this to allow a JRF domain to reuse its entries in the RCU database (specify a wallet file that was obtained from the domain home while the domain was booted for the first time).
 
@@ -6,6 +6,10 @@ pre = "<b> </b>"
 description = "Debugging a deployed Model in Image domain."
 +++
 
+{{% notice info %}}
+This feature is supported only in 3.0.0-RC1.
+{{% /notice %}}
+
 #### Contents
 
  - [Introduction](#introduction)
@@ -56,7 +60,7 @@ For example, assuming your domain UID is `sample-domain1` and your domain namesp
   # kubectl -n sample-domain1-ns logs pod/sample-domain1-introspect-domain-job-v2l7k
   ```
 
-  A common reason for the introspector job to fail is because of a typo in a model file. Here's some sample log output from an introspector job that shows such a failure:
+  A common reason for the introspector job to fail is because of an error in a model file. Here's some sample log output from an introspector job that shows such a failure:
 
   ```
   ...
@@ -67,7 +71,7 @@ For example, assuming your domain UID is `sample-domain1` and your domain namesp
 
 #### Check the WebLogic Server pods
 
-If your introspector job succeeded, then there will be no introspector job or pod, the operator will create a `MY_DOMAIN_UID-weblogic-domain-introspect-cm` config map for your domain, and the operator will then run the domain's WebLogic pods.
+If your introspector job succeeded, then there will be no introspector job or pod, the operator will create a `MY_DOMAIN_UID-weblogic-domain-introspect-cm` ConfigMap for your domain, and the operator will then run the domain's WebLogic pods.
 
 If `kubectl -n MY_NAMESPACE get pods` reveals that your WebLogic pods have errors, then use `kubectl -n MY_NAMESPACE describe pod POD_NAME` and `kubectl -n MY_NAMESPACE logs POD_NAME` to debug.
 
 
@@ -6,6 +6,10 @@ pre = "<b> </b>"
 description = "Model file requirements, macros, and loading order."
 +++
 
+{{% notice info %}}
+This feature is supported only in 3.0.0-RC1.
+{{% /notice %}}
+
 #### Contents
 
  - [Introduction](#introduction)
@@ -26,7 +30,7 @@ This document describes basic Model in Image model file syntax, naming, and macr
 
 #### Sample model file
 
-Here's an example of a model `.yaml` file that defines a WebLogic Server Administration Server and dynamic cluster.
+Here's an example of a model YAML file that defines a WebLogic Server Administration Server and dynamic cluster.
 
 ```
 domainInfo:
@@ -54,14 +58,13 @@ topology:
       ListenPort: 8001
 ```
 
-Some notes about the sample model file:
- - It includes a WebLogic credentials stanza that is required by Model in Image.
- - It derives its domain name from the pre-defined environment variable `DOMAIN_UID`, but note that this is not required.
- - For a description of model file macro references to secrets and environment variables, see [Model file macros](#model-file-macros).
+This sample model file:
+ - Includes a WebLogic credentials stanza that is required by Model in Image.
+ - Derives its domain name from the predefined environment variable `DOMAIN_UID`, but note that this is not required.
 
-#### Important notes about Model in Image model files
+For a description of model file macro references to secrets and environment variables, see [Model file macros](#model-file-macros).
 
-- Understand when to use model macros.
+#### Important notes about Model in Image model files
 
   - You can use model macros to reference arbitrary secrets from model files. This is recommended for handling mutable values such as database user names, passwords, and URLs. See [Using secrets in model files](#using-secrets-in-model-files).
 
@@ -86,11 +89,17 @@ Some notes about the sample model file:
 
 Refer to this section if you need to control the order in which your model files are loaded.  The order is important when two or more model files refer to the same configuration, because the last model that's loaded has the highest precedence.
 
-During domain home creation, model and property files are first loaded from the `/u01/model_home/models` directory within the image and are then loaded from the optional WDT config map described in [Optional WDT model config map]({{< relref "/userguide/managing-domains/model-in-image/usage/_index.md#3-optional-wdt-model-config-map" >}}).
+During domain home creation, model and property files are first loaded from the `/u01/model_home/models` directory within the image and are then loaded from the optional WDT ConfigMap described in [Optional WDT model ConfigMap]({{< relref "/userguide/managing-domains/model-in-image/usage/_index.md#3-optional-wdt-model-configmap" >}}).
+
+The loading order within each of these locations is first determined using the convention `filename.##.yaml` and `filename.##.properties`, where `##` are digits that specify the desired order when sorted numerically. Additional details:
 
-The loading order within each of these locations is first determined using the convention `filename.##.yaml` and `filename.##.properties`, where `##` is a numeric number that specifies the desired order, and then is determined alphabetically as a tie-breaker. File names that don't include `.##.` sort _before_ other files as if they implicitly have the lowest possible `.##.`.
+ * Embedding a `.##.` in a filename is optional and can appear anywhere in the file name before the `properties` or `yaml` extension.
+   * The precedence of file names that include more than one `.##.` is undefined. 
+   * The number can be any integer greater than or equal to zero. 
+ * File names that don't include `.##.` sort _before_ other files as if they implicitly have the lowest possible `.##.`  
+ * If two files share the same number, the loading order is determined alphabetically as a tie-breaker. 
 
-If an image file and config map file both have the same name, then both files are loaded.
+If an image file and ConfigMap file both have the same name, then both files are loaded.
 
 For example, if you have these files in the image directory `/u01/model_home/models`:
 
@@ -101,7 +110,7 @@ my-model.10.yaml
 y.yaml  
 ```
 
-And you have these files in the config map:
+And you have these files in the ConfigMap:
 
 ```
 jdbc-dev-urlprops.10.yaml