doc updates

Author: markxnelson

site/architecture.md

@@ -53,7 +53,6 @@ Within the container, the following aspects are configured by the operator:
 * The liveness probe is configured to check that the server is alive by querying the Node Manager process.  The liveness probe is configured to check liveness every 15 seconds, and to timeout after five seconds.  If a pod fails the liveness probe, Kubernetes will restart that container, and possibly the pod.
 *	The readiness probe is configured to use the WebLogic Server ReadyApp.  The readiness probe is used to determine if the server is ready to accept user requests.  The readiness is used to determine when a server should be included in a load balancer Ingress, when a restarted server is fully started in the case of a rolling restart, and for various other purposes.
 *	A shutdown hook is configured that will execute a script that performs a graceful shutdown of the server.  This ensures that servers have an opportunity to shut down cleanly before they are killed.
-*	If the Prometheus integration was configured, then the WebLogic Monitoring Exporter application will be installed on the server.  This application makes WebLogic Server metrics available to Prometheus.
 
 ## Domain state stored outside Docker images
 The operator expects (and requires) that all state be stored outside of the Docker images that are used to run the domain.  This means either in a persistent file system, or in a database.  The WebLogic configuration, i.e. the domain directory, the applications directory, file-based persistent stores, etc., are stored on a persistent volume.  A database could also be used to host persistent stores.  All of the containers that are participating in the WebLogic domain use the exact same image, and take on their personality; i.e., which server they execute, at startup time.  Each container mounts the same shared storage and has access to the state information that it needs to fulfill its role in the domain.

site/creating-domain.md

@@ -221,9 +221,6 @@ spec:
 
 The lines omitted at the end contain the actual scripts that are executed in this container.  These should generally not be modified, except by developers.  
 
-write more about the file
-
-
 ## Verifying the domain creation
 
 The script will verify that the domain was created, and will report failure if there was any error.  However, it may be desirable to manually verify the domain, even if just to gain familiarity with the various Kubernetes objects that were created by the script.
@@ -373,5 +370,3 @@ Events:  <none>
 Kubernetes has a concept of “readiness” that is used to determine when external requests should be routed to a particular pod.  The domain creation job provided with the operator configures the readiness probe to use the WebLogic Server ReadyApp, which provides a mechanism to check when the server is actually ready to process work, as opposed to simply being in the RUNNING state.  Often applications have some work to do after the server is RUNNING but before they are ready to process new requests.
 
 ReadyApp provides an API that allows an application to register itself, so that its state will be taken into consideration when determining if the server is “ready”, and an API that allows the application to inform ReadyApp when it considers itself to be ready.
-
-Add details of how to use ReadyApp API

site/starting-domain.md

@@ -87,7 +87,6 @@ spec:
   # - T3Channel
 ```
 
-write me
 
 ## How the operator determines which servers to start
 

site/wlst.md

@@ -38,5 +38,3 @@ wls:/base_domain/serverConfig/> exit()
 
 Exiting WebLogic Scripting Tool.
 ```
-
-write me