review/edit sample READMEs

Author: rosemarymarano

kubernetes/samples/README.md

@@ -1,11 +1,10 @@
 # WebLogic operator samples
 
-These samples are intended to provide simple demonstrations of how to accomplish common tasks.
-The samples are **not** intended to be used in production deployments or to be depended on to 
-create production environments.  They are provided as-is for educational and demonstration purposes.
+These samples provide simple demonstrations of how to accomplish common tasks.
+The samples are **not** intended to be used in production deployments or to be depended upon to
+create production environments.  They are provided for educational and demonstration purposes only.
 
-While these samples may be useful and usable as-is, it is intended that you would read through all of the sample code in detail, understand how the
-given sample works and then customize it to suit your needs.  
+While these samples may be useful and usable as is, it is intended that you would read through all of the sample code in detail, understand how the given sample works, and then customize it to suit your needs.  
 
 ## Sample scripts
 

kubernetes/samples/scripts/create-weblogic-domain-credentials/README.md

@@ -1,9 +1,9 @@
 # Creating credentials for a WebLogic domain
 
-This sample demonstrates how to create a Kubernetes secret containing the 
+This sample demonstrates how to create a Kubernetes secret containing the
 credentials for a WebLogic domain.  The operator expects this secret to be
 named following the pattern `domainUID-weblogic-credentials`, where `domainUID`
-is the unique identifier of the domain.  It must be in the same namespace 
+is the unique identifier of the domain.  It must be in the same namespace
 that the domain will run in.
 
 To use the sample, run the command:
@@ -15,17 +15,17 @@ $ ./create-weblogic-credentials.sh -u username -p password -d domainUID -n names
 The parameters are as follows:
 
 ```  
-  -u username, must be specified.
+  -u user name, must be specified.
   -p password, must be specified.
   -d domainUID, optional. The default value is domain1. If specified, the secret will be labeled with the domainUID unless the given value is an empty string.
-  -n namespace, optional. Use the default namespace if not specified
-  -s secretName, optional. If not specified, the secret name will be determined based on the domainUID value
+  -n namespace, optional. Use the default namespace if not specified.
+  -s secretName, optional. If not specified, the secret name will be determined based on the domainUID value.
 ```
 
-This creates a `generic` secret containing the username and password as literal values.
+This creates a `generic` secret containing the user name and password as literal values.
 
 You can check the secret with the `kubectl get secret` command.  An example is shown below,
-including output:
+including the output:
 
 ```
 $ kubectl -n domain-namespace-1 get secret domain1-weblogic-credentials -o yaml
@@ -46,4 +46,4 @@ metadata:
   uid: 0c2b3510-fe4c-11e8-994d-00001700101d
 type: Opaque
 
-```
+```

kubernetes/samples/scripts/create-weblogic-domain-pv-pvc/README.md

@@ -63,7 +63,7 @@ The PV and PVC creation inputs can be customized by editing the `create-pv-pvc-i
 
 By default, the `domainUID` is left empty in the inputs file, which means the generated PV and PVC will not be associated with a particular domain, but can be shared by multiple domain resources in the same Kubernetes namespaces as the PV and PVC.
 
-For the use cases where dedicated PV and PVC are desired for a particular domain, the `domainUID` needs to be set in the `create-pv-pvc-inputs.yaml` file. The presence of a non-empty domainUID in the inputs file will cause the generated PV and PVC to be associated with the specified `domainUID`. The association includes that the names of the generated YAML files and the Kubernetes PV and PVC objects are decorated with the `domainUID`, and the PV and PVC objects are also labeled with the `domainUID`.
+For the use cases where dedicated PV and PVC are desired for a particular domain, the `domainUID` needs to be set in the `create-pv-pvc-inputs.yaml` file. The presence of a non-empty `domainUID` in the inputs file will cause the generated PV and PVC to be associated with the specified `domainUID`. The association includes that the names of the generated YAML files and the Kubernetes PV and PVC objects are decorated with the `domainUID`, and the PV and PVC objects are also labeled with the `domainUID`.
 
 ## Verify the results
 

kubernetes/samples/scripts/create-weblogic-domain/domain-home-in-image/README.md

@@ -27,8 +27,8 @@ The script will perform the following steps:
 
 * Create a directory for the generated properties and Kubernetes YAML files for this domain if it does not already exist.  The pathname is `/path/to/weblogic-operator-output-directory/weblogic-domains/<domainUID>`. If the directory already exists, its contents will be removed.
 * Create a properties file, `domain.properties`, in the directory that is created above. This properties file will be used to create a sample WebLogic Server domain.
-* Clone the weblogic docker-images project via the `git clone https://github.com/oracle/docker-images.git` into the current directory.
-* Replace the built-in username and password in the `properties/docker-build/domain_security.properties` file with the `username` and `password` that are supplied in the command line via the `-u` and `-p` options. These credentials need to match the WebLogic domain admin credentials in the secret that is specified via `weblogicCredentialsSecretName` property in the `create-domain-inputs.yaml` file.
+* Clone the weblogic docker-images project into the current directory using `git clone https://github.com/oracle/docker-images.git`.
+* Replace the built-in user name and password in the `properties/docker-build/domain_security.properties` file with the `username` and `password` that are supplied on the command line using the `-u` and `-p` options. These credentials need to match the WebLogic domain admin credentials in the secret that is specified via the `weblogicCredentialsSecretName` property in the `create-domain-inputs.yaml` file.
 * Build a Docker image based on the Docker sample, [Example Image with a WebLogic Server Domain using the Oracle WebLogic Deploy Tooling (WDT)](https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/12213-domain-home-in-image-wdt) and [Example Image with a WebLogic Server Domain using WLST](https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/12213-domain-home-in-image). It will create a sample WebLogic Server domain in the Docker image. Also, you can run the Docker sample, [Example Image with a WebLogic Server Domain](https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/12213-domain-home-in-image), manually with the generated `domain.properties` to create a domain home image. **Note**: Oracle recommends keeping the domain home image private in the local repository.
 * Create a Kubernetes domain YAML file, `domain.yaml`, in the directory that is created above. This YAML file can be used to create the Kubernetes resource using the `kubectl create -f` or `kubectl apply -f` command.
 
@@ -44,7 +44,7 @@ usage: create-domain.sh -o dir -i file -u username -p password [-k] [-e] [-h]
   -u Username used in building the Docker image for WebLogic domain in image.
   -p Password used in building the Docker image for WebLogic domain in image.
   -e Also create the resources in the generated YAML files, optional.
-  -k Keep what has been previously cloned from https://github.com/oracle/docker-images.git, optional. 
+  -k Keep what has been previously cloned from https://github.com/oracle/docker-images.git, optional.
      If not specified, this script will always remove existing project and clone again.
   -h Help
 
@@ -139,7 +139,7 @@ spec:
   includeServerOutInPodLog: true
   # serverStartPolicy legal values are "NEVER", "IF_NEEDED", or "ADMIN_ONLY"
   # This determines which WebLogic Servers the Operator will start up when it discovers this Domain
-  # - "NEVER" will not start any servers in the domain 
+  # - "NEVER" will not start any servers in the domain
   # - "ADMIN_ONLY" will start up only the administration server (no managed servers will be started)
   # - "IF_NEEDED" will start all non-clustered servers, including the administration server and clustered servers up to the replica count
   serverStartPolicy: "IF_NEEDED"

kubernetes/samples/scripts/elasticsearch-and-kibana/README.md

@@ -14,8 +14,8 @@ It's useful for trying out the operator in a Kubernetes cluster that doesn't alr
 have them configured.
 
 It runs Elasticstack on the same host and port that the operator's Helm chart defaults
-to, therefore, the customer only needs to set elkIntegrationEnabled to true in their
-`values.yaml` file.
+to, therefore, the customer only needs to set `elkIntegrationEnabled` to `true` in their
+`values.yaml` file.``
 
 To install ElasticSearch and Kibana, use:
 ```

kubernetes/samples/scripts/rest/README.md

@@ -1,13 +1,13 @@
 # Sample to create certificates and keys for the operator
 
-When a user enables the operator's external REST api (by setting
-`externalRestEnabled` to `true` when installing the operator helm chart), the user needs
-to provide the certificate and private key for api's SSL identity (by setting
+When a user enables the operator's external REST API (by setting
+`externalRestEnabled` to `true` when installing the operator Helm chart), the user needs
+to provide the certificate and private key for the API's SSL identity (by setting
 `externalOperatorCert` and `externalOperatorKey` to the base64 encoded PEM of the cert and
-key when installing the operator helm chart).
+key when installing the operator Helm chart).
 
 This sample script generates a self-signed certificate and private key that can be used
-for the operator's external REST api when experimenting with the operator.  They should
+for the operator's external REST API when experimenting with the operator.  They should
 not be used in a production environment.
 
 The syntax of the script is:
@@ -16,7 +16,7 @@ $ kubernetes/samples/scripts/generate-external-rest-identity.sh <subject alterna
 ```
 
 Where `<subject alternative names>` lists the subject alternative names to put into the generated
-self-signed certificate for the external WebLogic Operator REST https interface.  Each must be prefaced 
+self-signed certificate for the external WebLogic Operator REST HTTPS interface.  Each must be prefaced
 by `DNS:` (for a name) or `IP:` (for an address), for example:
 ```
 DNS:myhost,DNS:localhost,IP:127.0.0.1
@@ -25,13 +25,13 @@ DNS:myhost,DNS:localhost,IP:127.0.0.1
 You should include the addresses of all masters and load balancers in this list.  The certificate
 cannot be conveniently changed after installation of the operator.
 
-The script prints out the base64 encoded pem of the generated certificate and private key
-in the same format that the operator helm chart's `values.yaml` requires.
+The script prints out the base64 encoded PEM of the generated certificate and private key
+in the same format that the operator Helm chart's `values.yaml` requires.
 
 Example usage:
 ```
 $  generate-external-rest-identity.sh IP:127.0.0.1 > my_values.yaml
 $  echo "externalRestEnabled: true" >> my_values.yaml
    ...
 $  helm install kubernetes/charts/weblogic-operator --name my_operator --namespace my_operator-ns --values my_values.yaml --wait
-```
+```

site/persistent-volumes.md

@@ -1,4 +1,4 @@
-**TODO** review 
+
 
 # Persistent volumes
 
@@ -14,14 +14,14 @@ The following prerequisites must be fulfilled before proceeding with the creatio
 ## Storage locations
 Persistent volumes can point to different storage locations, for example NFS servers or a local directory path. The list of available options is listed in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/persistent-volumes/).
 
-**Note** regarding NFS:
+**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.
+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.
 
 # 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 2 YAML templates, one for the volume and one for the claim. As stated above, they can either 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.
+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.
 
 For sample YAML templates, refer to the [Persistent volumes example](../kubernetes/samples/scripts/create-weblogic-domain-pv-pvc/README.md).