updates from review

Author: markxnelson

docs-source/content/userguide/cicd/_index.md

@@ -1,5 +1,5 @@
 ---
-title: "CI/CD"
+title: "CI/CD considerations"
 date: 2019-04-11T13:01:55-04:00
 weight: 5
 description: "Learn about managing domain images with CI/CD."

docs-source/content/userguide/cicd/choose-an-approach.md

@@ -13,7 +13,8 @@ various approaches.  We can start by asking ourselves questions like these:
 - *Can you make the desired change with a configuration override?*  
   The WebLogic Kubernetes Operator allows you to inject a number of [configuration
   overrides]({{< relref "/userguide/managing-domains/configoverrides/_index.md" >}})
-  into your pods at startup time.  This allows you to use the same image for multiple
+  into your pods before starting any servers in the domain.  This allows you to use 
+  the same image for multiple
   different configurations.  A good example would be changing the settings for a data
   source, for example. You may wish to have a larger connection pool in your production
   environment than you do in your development/test environments.  You probably also
@@ -29,7 +30,7 @@ various approaches.  We can start by asking ourselves questions like these:
   If your changes fit into this category, and you have used the "domain-in-image"
   approach and the Docker layering model, then you only need to update the top layer
   of your image.  This is relatively easy compared to making changes in lower layers.
-  You could create a new layer with the changes, or your could rebuild/replace the
+  You could create a new layer with the changes, or you could rebuild/replace the
   existing top layer with a new one.  Which approach you choose depends mainly on
   whether you need to maintain the same domain encryption keys or not.
 - *Do you need to be able to do a rolling restart?*

docs-source/content/userguide/cicd/how-to-copy-domains.md

@@ -13,22 +13,25 @@ the same location (Domain Home) in the (new) file system.  Using this
 approach will maintain the same domain encryption key.  
 
 The best practice/recommended approach is to create a "primordial domain"
-(as described previously) which does not contain any applications or resources,
+which does not contain any applications or resources,
 and to create a ZIP file of this domain before starting any servers.  
 
-
 > The domain ZIP must be created before starting servers.  
 
 When servers are started the first time, they will encrypt various other data.
 Make sure you create the ZIP file before starting servers for the first time.
 The primordial domain ZIP file should be stored in a safe place where the CI/CD
 can get it when needed, for example in a secured Artifactory repository (or
-something similar).  Remember, anyone who gets access to this ZIP file can get access
+something similar).  
+
+{{% notice warning %}}
+Remember, anyone who gets access to this ZIP file can get access
 to the domain encryption key, so it needs to be protected appropriately.
+{{% /notice %}}
 
 Every time you run your CI/CD pipeline to create a new mutation of the domain,
 it should retrieve and unzip the primordial domain first, and then apply changes
-to that domain using tools like WDT or WLST (see below).
+to that domain using tools like WDT or WLST (see [here]({{< relref "/userguide/cicd/tools.md" >}})).
 
 
 > Always use external state.

docs-source/content/userguide/cicd/why-layering-matters.md

@@ -33,11 +33,10 @@ small, then we will just end up with another small layer, and as we have seen,
 the small layers are no problem.
 
 But consider a more complicated scenario - let's take updating the JDK as an example
-to understand the impact of layers.  Say we want to update from JDK 11.0.2 to 11.0.4
-as shown in the example above - this is just an example, WebLogic 12.2.1.3 does not
-support JDK 11!  If we took the "your first domain" image and updated
-the JDK, then we would end up with a new layer on top containing JDK 11.0.4.  That
-other layer with JDK 11.0.2 is still there; even if we "delete" the directory, we
+to understand the impact of layers.  Say we want to update from JDK 8u201 to 8u202
+as shown in the example above.  If we took the "your first domain" image and updated
+the JDK, then we would end up with a new layer on top containing JDK 8u202.  That
+other layer with JDK 8u201 is still there; even if we "delete" the directory, we
 don't get that space back.  So now our 1.5GB "image" has grown to 1.75GB.  This is
 not ideal, and the more often we try to change lower layers, the worse it gets.