Merge branch 'develop' of https://github.com/oracle/weblogic-kubernetes-operator into jrftest2

Author: xiancao

docs-source/content/developerguide/building.md

@@ -27,7 +27,7 @@ $ mvn fmt:format
 To build the Javadoc for the operator, issue the following command:
 
 ```
-$ mvn javadoc:javadoc
+$ mvn javadoc:aggregate
 ```
 
 The Javadoc is also available in the GitHub repository [here](https://oracle.github.io/weblogic-kubernetes-operator/apidocs/index.html).

docs-source/content/recent-changes.md

@@ -10,7 +10,7 @@ This document tracks recent changes to the operator, especially ones that introd
 
 | Date | Version | Introduces backward incompatibilities | Change |
 | --- | --- | --- | --- |
-| TBD | v2.2 | no  | Added support for FMW Infrastructure domains. WebLogic server instances are now gracefully shutdown by default and shutdown options are configurable. Operator is now built and runs on JDK 11. 
+| May 6, 2019 | v2.2 | no  | Added support for FMW Infrastructure domains. WebLogic Server instances are now gracefully shut down by default and shutdown options are configurable. Operator is now built and runs on JDK 11. 
 | April 4, 2019 | v2.1 | no  | Customers can add init and sidecar containers to generated pods.  
 | March 4, 2019 | v2.0.1 | no  | OpenShift support is now certified.  Many bug fixes, including fixes for configuration overrides, cluster services, and domain status processing.  
 | January 24, 2019 | v2.0 | yes; not compatible with 1.x releases, but is compatible with 2.0-rc2. | Final version numbers and documentation updates.  

docs-source/content/release-notes.md

@@ -8,7 +8,7 @@ draft: false
 
 | Date | Version | Introduces backward incompatibilities | Change |
 | --- | --- | --- | --- |
-| TBD | v2.2 | no  | Added support for FMW Infrastructure domains. WebLogic Server instances are now gracefully shutdown by default and shutdown options are configurable. Operator is now built and runs on JDK 11. 
+| May 6, 2019 | v2.2 | no  | Added support for FMW Infrastructure domains. WebLogic Server instances are now gracefully shut down by default and shutdown options are configurable. Operator is now built and runs on JDK 11. 
 | April 4, 2019 | v2.1 | no  | Customers can add init and sidecar containers to generated pods.  
 | March 4, 2019 | v2.0.1 | no  | OpenShift support is now certified.  Many bug fixes, including fixes for configuration overrides, cluster services, and domain status processing.  
 | January 24, 2019 | v2.0 | yes; not compatible with 1.x releases, but is compatible with 2.0-rc2. | Final version numbers and documentation updates.  

docs-source/content/userguide/managing-domains/domain-lifecycle/startup.md

@@ -16,8 +16,8 @@ and which servers should be restarted. To start, stop, or restart servers, modif
     * [Rolling restarts](#rolling-restarts)
     * [Common restarting scenarios](#common-restarting-scenarios)
 
-There are properties on the domain resource that specify which servers should be running
-and which servers should be restarted. To start, stop, or restart servers, modify these properties on the domain resource
+There are properties on the domain resource that specify which servers should be running,
+which servers should be restarted and the desired initial state. To start, stop, or restart servers, modify these properties on the domain resource
 (for example, by using `kubectl` or the Kubernetes REST API).  The operator will notice the changes and apply them.  Beginning,
 with operator version 2.2, there are now properties to control server shutdown handling, such as whether the shutdown
 will be graceful, the timeout, and if in-flight sessions are given the opportunity to complete.
@@ -69,6 +69,16 @@ Servers configured as `ALWAYS` count toward the cluster's `replicas` count.
 If more servers are configured as `ALWAYS` than the cluster's `replicas` count, they will all be started and the `replicas` count will be ignored.
 {{% /notice %}}
 
+### Server start state
+
+For some use cases, such as an externally managed zero downtime patching (ZDP), it may be necessary to start WebLogic Server
+so that at the end of its startup process, the server is in an administrative state.  This can be achieved using the `serverStartState`
+property, which is available at domain, cluster, and server levels.  When `serverStartState` is set to `ADMIN`, then servers will
+progress only to the administrative state.  You could then use the WebLogic console, REST API, or a WLST script to make any necessary
+updates before advancing the server to the running state.
+
+Changes to the `serverStartState` property do not affect already started servers.
+
 ### Common starting and stopping scenarios
 
 #### Normal running state
@@ -240,7 +250,6 @@ The operator will restart servers when any of the follow properties on the domai
 * `readinessProbe`
 * `resources`
 * `restartVersion`
-* `serverStartState`
 * `volumes`
 * `volumeMounts`
 
@@ -251,6 +260,11 @@ the domain resource will cause neither a restart nor a patch. It is possible to
 such a label or annotation by modifying the `restartVersion`.
 {{% /notice %}}
 
+{{% notice note %}}
+Prior to version 2.2, the operator incorrectly restarted servers when the `serverStartState` property was changed.  Now, 
+this property has no affect on already running servers.
+{{% /notice %}}
+
 ### Rolling restarts
 
 Clustered servers that need to be restarted are gradually restarted (for example, `rolling restarted`) so that the cluster is not taken out of service and in-flight work can be migrated to other servers in the cluster.

docs-source/content/userguide/managing-domains/persistent-storage/_index.md

@@ -43,8 +43,8 @@ $ chmod 770 /path/to/domain1PersistentVolume
 $ kubectl annotate pv domain1-weblogic-sample-pv pv.beta.kubernetes.io/gid=6789
 ```
 
-Typically, after the domain is created and servers are running, the group ownership of the persistent volume files
-can be updated to the specified GID which will provide read access to the group members. Normally
+After the domain is created and servers are running, the group ownership of the persistent volume files
+can be updated to the specified GID which will provide read access to the group members. Typically,
 files created from a pod onto the persistent volume will have UID `1000` and GID `1000` which is the
 `oracle` user from the WebLogic Docker image.