update to develop branch

Author: rosemarymarano

docs-source/content/userguide/managing-domains/configoverrides/_index.md

@@ -61,21 +61,21 @@ For a detailed walk-through of the runtime flow, see the [Internal design flow](
 
 * A WebLogic domain home must not contain any situational configuration XML file in its `optconfig` directory that was not placed there by the operator. Any existing situational configuration XML files in this directory will be deleted and replaced by your operator override templates (if any).
 
-* If you want to override a JDBC, JMS, or WLDF (diagnostics) module, the original module must be located in your domain home `config/jdbc`, `config/jms`, and `config/diagnostics` directory, respectively. These are the default locations for these types of modules.
+* If you want to override a JDBC, JMS, or WLDF (diagnostics) module, then the original module must be located in your domain home `config/jdbc`, `config/jms`, and `config/diagnostics` directory, respectively. These are the default locations for these types of modules.
 
 ---
 ### Typical overrides
 
 Typical attributes for overrides include:
 
 * User names, passwords, and URLs for:
-  * JDBC datasources
+  * JDBC data sources
   * JMS bridges, foreign servers, and SAF
 * Network channel public addresses:
   * For remote RMI clients (T3, JMS, EJB, JTA)
   * For remote WLST clients
 * Debugging
-* Tuning (`MaxMessageSize`, etc.)
+* Tuning (`MaxMessageSize`, and such)
 
 ---
 ### Unsupported overrides
@@ -187,13 +187,14 @@ The secret macro `SECRETNAME` field must reference the name of a Kubernetes secr
 **Check each item below to ensure custom situational configuration takes effect:**
 
 * Reference the name of the current bean and each parent bean in any hierarchy you override.
+  * Note that the `combine-mode` verbs (`add` and `replace`) should be omitted for beans that are already defined in your original domain home configuration.
   * See [Override template samples](#override-template-samples) for examples.
 * Use situational config `replace` and `add` verbs as follows:
-  * If you are adding a new bean that doesn't already exist in your original domain home `config.xml`, specify `add` on the MBean itself and on each attribute within the bean.
+  * If you are adding a new bean that doesn't already exist in your original domain home `config.xml`, then specify `add` on the MBean itself and on each attribute within the bean.
     * See the `server-debug` stanza in [Override template samples](#override-template-samples) for an example.
-  * If you are adding a new attribute to an existing bean in the domain home `config.xml`, the attribute needs an `add` verb.
+  * If you are adding a new attribute to an existing bean in the domain home `config.xml`, then the attribute needs an `add` verb.
     * See the `max-message-size` stanza in [Override template samples](#override-template-samples) for an example.
-  * If you are changing the value of an existing attribute within a domain home `config.xml`, the attribute needs a `replace` verb.
+  * If you are changing the value of an existing attribute within a domain home `config.xml`, then the attribute needs a `replace` verb.
     * See the `public-address` stanza in  [Override template samples](#override-template-samples) for an example.
 * When overriding `config.xml`:
   * The XML namespace (`xmlns:` in the XML) must be exactly as specified in [Override template schemas](#override-template-schemas).
@@ -274,7 +275,7 @@ The following `jdbc-testDS.xml` override template demonstrates setting the URL,
   * Templates can embed macros that reference environment variables or Kubernetes secrets.  See [Override template macros](#override-template-macros).
 * Create a Kubernetes configuration map from the directory of templates.
   * The configuration map must be in the same Kubernetes namespace as the domain.
-  * If the configuration map is going to be used by a single `DOMAIN_UID`, we recommend adding the `weblogic.domainUID=<mydomainuid>` label to help track the resource.
+  * If the configuration map is going to be used by a single `DOMAIN_UID`, then we recommend adding the `weblogic.domainUID=<mydomainuid>` label to help track the resource.
   * For example, assuming `./mydir` contains your `version.txt` and situation configuration template files:
     ```
     kubectl -n MYNAMESPACE create cm MYCMNAME --from-file ./mydir
@@ -283,15 +284,15 @@ The following `jdbc-testDS.xml` override template demonstrates setting the URL,
 * Create any Kubernetes secrets referenced by a template 'secret macro'.
   * Secrets can have multiple keys (files) that can hold either cleartext or base64 values. We recommend that you use base64 values for passwords via `Opaque` type secrets in their `data` field, so that they can't be easily read at a casual glance. For more information, see https://kubernetes.io/docs/concepts/configuration/secret/.
   * Secrets must be in the same Kubernetes namespace as the domain.
-  * If a secret is going to be used by a single `DOMAIN_UID`, we recommend adding the `weblogic.domainUID=<mydomainuid>` label to help track the resource.
+  * If a secret is going to be used by a single `DOMAIN_UID`, then we recommend adding the `weblogic.domainUID=<mydomainuid>` label to help track the resource.
   * For example:
     ```
     kubectl -n MYNAMESPACE create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret
     kubectl -n MYNAMESPACE label secret my-secret weblogic.domainUID=DOMAIN_UID
     ```
 * Configure the name of the configuration map in the domain CR `configOverrides` field.
 * Configure the names of each secret in domain CR.
-  * If the secret contains the WebLogic admin `username` and `password` keys, set the domain CR `webLogicCredentialsSecret` field.
+  * If the secret contains the WebLogic admin `username` and `password` keys, then set the domain CR `webLogicCredentialsSecret` field.
   * For all other secrets, add them to the domain CR `configOverrideSecrets` field. Note: This must be in an array format even if you only add one secret (see the sample domain resource YAML below).
 * Any override changes require stopping all WebLogic pods, applying your domain resource (if it changed), and restarting the WebLogic pods before they can take effect.
   * Custom override changes on an existing running domain, such as updating an override configuration map, a secret, or a domain resource, will not take effect until all running WebLogic Server pods in your domain are shutdown (so no servers are left running), and the domain is subsequently restarted with your new domain resource (if it changed), or with your existing domain resource (if you haven't changed it).
@@ -322,7 +323,7 @@ spec:
 ---
 ### Debugging
 
-Incorrectly formatted override files may be accepted without warnings or errors, and will not prevent WebLogic pods from booting. So it is important to make sure that the template files are correct in a QA environment, otherwise your WebLogic Servers may start even though critically required overrides are failing to take effect.
+Incorrectly formatted override files may be accepted without warnings or errors and will not prevent WebLogic pods from booting. So, it is important to make sure that the template files are correct in a QA environment, otherwise your WebLogic Servers may start even though critically required overrides are failing to take effect.
 
 * Make sure you've followed each step in the [Step-by-step guide](#step-by-step-guide).
 
@@ -335,7 +336,7 @@ Incorrectly formatted override files may be accepted without warnings or errors,
 
 * If WebLogic pods do start, then:
   * Search your Administration Server pod's `kubectl log` for the keyword `situational`, for example `kubectl logs MYADMINPOD | grep -i situational`.
-    * The only WebLogic Server log lines that match should look something like like:
+    * The only WebLogic Server log lines that match should look something like:
       * `<Dec 14, 2018 12:20:47 PM UTC> <Info> <Management> <BEA-141330> <Loading situational configuration file: /shared/domains/domain1/optconfig/custom-situational-config.xml>`
       * This line indicates a situational configuration file has been loaded.
     * If the search yields Warning or Error lines, then the format of the custom situational configuration template is incorrect, and the Warning or Error text should describe the problem.
@@ -350,9 +351,9 @@ Incorrectly formatted override files may be accepted without warnings or errors,
          ```
   * Look in your `DOMAIN_HOME/optconfig` directory.
     * This directory, or a subdirectory within this directory, should contain each of your custom situational configuration files.
-    * If it doesn't, this likely indicates your domain resource `configOverrides` was not set to match your custom override configuration map name, or that your custom override configuration map does not contain your override files.
+    * If it doesn't, then this likely indicates your domain resource `configOverrides` was not set to match your custom override configuration map name, or that your custom override configuration map does not contain your override files.
 
-* If you'd like to verify that the situational configuration is taking effect in the WebLogic MBean tree, one way to do this is to compare the `server config` and `domain config` MBean tree values.
+* If you'd like to verify that the situational configuration is taking effect in the WebLogic MBean tree, then one way to do this is to compare the `server config` and `domain config` MBean tree values.
   * The `domain config` value should reflect the original value in your domain home configuration.
   * The `server config` value should reflect the overridden value.
   * For example, assuming your `DOMAIN_UID` is `domain1`, and your domain contains a WebLogic Server named `admin-server`, then:
@@ -373,7 +374,7 @@ Incorrectly formatted override files may be accepted without warnings or errors,
 -Dweblogic.debug.DebugSituationalConfigDumpXml=true
 ```
 
-* NOTE: The WebLogic console will _not_ reflect any override changes. You cannot use the console to verify overrides are taking effect.
+* **NOTE**: The WebLogic console will _not_ reflect any override changes. You cannot use the console to verify overrides are taking effect.
 
 
 ---
@@ -383,9 +384,9 @@ Incorrectly formatted override files may be accepted without warnings or errors,
 * The introspector job's pod:
   * Mounts the Kubernetes configuration map and secrets specified via the operator domain resource `configOverrides`, `webLogicCredentialsSecret`, and `configOverrideSecrets` fields.
   * Reads the mounted situational configuration templates from the configuration map and expands them to create the actual situational configuration files for the domain:
-    * It expands some fixed replaceable values (e.g. `${env:DOMAIN_UID}`).
-    * It expands referenced secrets by reading the value from the corresponding mounted secret file (e.g. `${secret:mysecret.mykey}`).
-    * It optionally encrypts secrets using offline WLST to encrypt the value - useful for passwords (e.g. `${secret:mysecret.mykey:encrypt}`).
+    * It expands some fixed replaceable values (for example, `${env:DOMAIN_UID}`).
+    * It expands referenced secrets by reading the value from the corresponding mounted secret file (for example, `${secret:mysecret.mykey}`).
+    * It optionally encrypts secrets using offline WLST to encrypt the value - useful for passwords (for example, `${secret:mysecret.mykey:encrypt}`).
     * It returns expanded situational configuration files to the operator.
     * It reports any errors when attempting expansion to the operator.
 * The operator runtime: