fixing domainuid for sessionmigration test

Author: vanajamukkara

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

@@ -22,14 +22,41 @@ Persistent volumes can point to different storage locations, for example NFS ser
 
 The persistent volume for the domain must be created using the appropriate tools before running the script to create the domain.  In the simplest case, namely the `HOST_PATH` provider, this means creating a directory on the Kubernetes master and ensuring that it has the correct permissions:
 
-```
+```bash
 $ mkdir -m 777 -p /path/to/domain1PersistentVolume
 ```
 
 **Note regarding NFS**: In the current GA version, the OCI Container Engine for Kubernetes supports network block storage that can be shared across nodes with access permission RWOnce (meaning that only one can write, others can read only). At this time, the WebLogic on Kubernetes domain created by the WebLogic Server Kubernetes Operator, requires a shared file system to store the WebLogic domain configuration, which MUST be accessible from all the pods across the nodes. As a workaround, you need to install an NFS server on one node and share the file system across all the nodes.
 
 Currently, we recommend that you use NFS version 3.0 for running WebLogic Server on OCI Container Engine for Kubernetes. During certification, we found that when using NFS 4.0, the servers in the WebLogic domain went into a failed state intermittently. Because multiple threads use NFS (default store, diagnostics store, Node Manager, logging, and `domain_home`), there are issues when accessing the file store. These issues are removed by changing the NFS to version 3.0.
 
+#### Persistent volume GID annotation
+
+The `HOST_PATH` directory permissions can be made more secure by using a Kubernetes annotation on the
+persistent volume that provides the group identifier (GID) which will be added to pods using the persistent volume.
+
+For example, if the GID of the directory is `6789`, then the directory can be updated to remove permissions
+other than for the user and group along with the persistent volume being annotated with the specified GID:
+
+```bash
+$ chmod 770 /path/to/domain1PersistentVolume
+$ kubectl annotate pv domain1-weblogic-sample-pv pv.beta.kubernetes.io/gid=6789
+```
+
+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.
+
+An example of updating the group ownership on the persistent volume would be as follows:
+
+```bash
+$ cd /path/to/domain1PersistentVolume
+$ sudo chgrp 6789 applications domains logs stores
+$ sudo chgrp -R 6789 domains/
+$ sudo chgrp -R 6789 logs/
+```
+
 ### YAML files
 
 Persistent volumes and claims are described in YAML files. For each persistent volume, you should create one persistent volume YAML file and one persistent volume claim YAML file. In the example below, you will find two YAML templates, one for the volume and one for the claim. As stated above, they either can be dedicated to a specific domain, or shared across multiple domains. For the use cases where a volume will be dedicated to a particular domain, it is a best practice to label it with `weblogic.domainUID=[domain name]`. This makes it easy to search for, and clean up resources associated with that particular domain.