Merge pull request #40 from oracle/prepare-doc-for-release

Prepare doc for release

Author: rjeberhard

README.md

@@ -1,6 +1,7 @@
 # Oracle WebLogic Server Kubernetes Operator
 
 Built with [Wercker](http://www.wercker.com)
+
 [![wercker status](https://app.wercker.com/status/68ce42623fce7fb2e52d304de8ea7530/m/master "wercker status")](https://app.wercker.com/project/byKey/68ce42623fce7fb2e52d304de8ea7530)
 
 Many organizations are exploring, testing, or actively moving application workloads into a cloud environment, either in house or using an external cloud provider.  Kubernetes has emerged as a leading cloud platform and is seeing widespread adoption.  But a new computing model does not necessarily mean new applications or workloads – many of the existing application workloads running in environments designed and built over many years, before the ‘cloud era’, are still mission critical today.  As such, there is a lot of interest in moving such workloads into a cloud environment, like Kubernetes, without forcing application rewrites, retesting and additional process and cost.  There is also a desire to not just run the application in the new environment, but to run it ‘well’ – to adopt some of the idioms of the new environment and to realize some of the benefits of that new environment.
@@ -100,9 +101,6 @@ If you would rather see the developers demonstrating the operator rather than re
 * [Deploying a web application, scaling a WebLogic cluster with the operator and verifying load balancing](https://youtu.be/hx4OPhNFNDM)
 * [Using WLST against a domain running in Kubernetes](https://youtu.be/eY-KXEk8rI4) shows how to create a data source for an Oracle database that is also running in Kubernetes.
 * [Scaling a WebLogic cluster with WLDF](https://youtu.be/Q8iZi2e9HvU)
-* [Prometheus integration](https://youtu.be/D7KWVXzzqx8) including exporting WebLogic Server metrics to Prometheus and creating a Prometheus alert to trigger scaling
-* [Shutting down a domain](#)
-* [Deleting a domain](#)
 * watch this space, more to come!
 
 Like what you see?  Read on for all the nitty-gritty details...
@@ -122,9 +120,9 @@ The overall process of installing and configuring the operator and using it to m
 *	Customizing the domain parameters file
 *	Creating a WebLogic domain
 
-These steps are explained in detail [here](site/installation.md). Example files are provided in the `kubernetes` directory in this repository.
+All of the [installation steps are explained in detail here](site/installation.md). Example files are provided in the `kubernetes` directory in this repository.
 
-If you need an Oracle database in your Kubernetes cluster, e.g. because your web application needs a place to keep its data, please see [this page](site/database.md) for information about how to run the Oracle database in Kubernetes.
+[comment]: # (If you need an Oracle database in your Kubernetes cluster, e.g. because your web application needs a place to keep its data, please see [this page] site/database.md for information about how to run the Oracle database in Kubernetes.)
 
 ## Using the operator's REST services
 
@@ -134,13 +132,7 @@ The operator provides a REST API that can be used to obtain information about th
 
 Please refer to [Creating a WebLogic domain with the operator](site/creating-domain.md) for information about how to create a WebLogic domain with the operator.
 
-## Manually creating a WebLogic domain
-
-If preferred, a domain can be created manually, i.e. without using the scripts provided with the operator.  As long as the domain follows the guidelines, it can still be managed by the operator.  Please refer to [Manually creating a WebLogic domain](site/manually-creating-domain.md) for details.  A good example of when manual domain creation may be preferred is when a user already has a set of existing WLST scripts that are used to create domains and they wish to reuse those same WLST scripts in Kubernetes, perhaps with some small modifications.
-
-## Exporting WebLogic metrics to Prometheus
-
-When using the operator to manage WebLogic domains, it may also be desirable to export WebLogic Server metrics to Prometheus using the [WLS Exporter](https://github.com/oracle/weblogic-monitoring-exporter), which allows metrics to be displayed in Grafana, and permits the creation of alerts and initiation of scaling actions from Prometheus alerts.  Please refer to [Prometheus integration](site/prometheus.md) for more information.
+[comment]: # ( Manually creating a WebLogic domain.  If preferred, a domain can be created manually, i.e. without using the scripts provided with the operator.  As long as the domain follows the guidelines, it can still be managed by the operator.  Please refer to [Manually creating a WebLogic domain] site/manually-creating-domain.md for details.  A good example of when manual domain creation may be preferred is when a user already has a set of existing WLST scripts that are used to create domains and they wish to reuse those same WLST scripts in Kubernetes, perhaps with some small modifications. )
 
 ## Starting up the domain
 
@@ -170,10 +162,7 @@ Please refer to [Shutting down a domain](site/shutdown-domain.md) for informatio
 The initial Technology Preview release of the operator supports only the Traefik load balancer/Ingress controller.  Support for other load balancers is planned in the future.
 Please refer to [Load balancing with the Traefik ingress controller](site/traefik.md) for information about current capabilities.
 
-## Exporting operator logs to ELK
-
-The operator provides an option to export its log files to the ELK stack.
-Please refer to [ELK integration](site/elk.md) for information about this capability.
+[comment]: # (Exporting operator logs to ELK.  The operator provides an option to export its log files to the ELK stack. Please refer to [ELK integration]site/elk.md for information about this capability.)
 
 ## Removing a domain
 
@@ -188,8 +177,6 @@ Find the names of the persistent volume claim and the persistent volume in the d
 
 To permanently delete the actual domain configuration, delete the physical volume using the appropriate tools.  For example, if the persistent volume used the `HostPath provider`, then delete the corresponding directory on the Kubernetes master.
 
-Be aware that there may be metric data from the domain in Prometheus if this option was used.  These data will need to be deleted separately, if desired.
-
 ## Removing the operator
 
 To remove the operator from a Kubernetes cluster, issue the following commands:

deploy.sh

@@ -1,9 +1,7 @@
 #!/bin/bash
-#  Copyright 2017, Oracle Corporation and/or affiliates.  All rights reserved.
+#  Copyright 2017, 2018, Oracle Corporation and/or affiliates.  All rights reserved.
 
-#IMAGE="container-registry.oracle.com/middleware/weblogic-kubernetes-operator:latest"
-# for early access builds:
-IMAGE="quay.io/markxnelson/weblogic-kubernetes-operator:latest"
+IMAGE="container-registry.oracle.com/middleware/weblogic-kubernetes-operator:latest"
 
 echo 'Building Docker image...'
 docker build -t $IMAGE --no-cache=true .

kubernetes/create-operator-inputs.yaml

@@ -14,9 +14,7 @@ namespace: weblogic-operator
 targetNamespaces: default
 
 # The docker image containing the operator code.
-# image: container-registry.oracle.com/middleware/weblogic-kubernetes-operator:latest
-# EARLY ACCESS IMAGE
-image: quay.io/markxnelson/weblogic-kubernetes-operator:latest
+image: container-registry.oracle.com/middleware/weblogic-kubernetes-operator:latest
 
 # The image pull policy for the operator docker image.
 imagePullPolicy: IfNotPresent

kubernetes/internal/weblogic-operator-template.yaml

@@ -102,7 +102,7 @@ spec:
       # Update the imagePullSecrets with the name of your Kubernetes secret containing
       # your credentials for the Oracle Container Registry.
       imagePullSecrets:
-      - name: earlybird-secret
+      - name: my-registry-secret
 
 ---
 %EXTERNAL_OPERATOR_SERVICE_PREFIX%apiVersion: v1

site/architecture.md

@@ -7,7 +7,7 @@ The operator consists of the following two main parts:
 
 The operator is packaged in a Docker image `container-registry.oracle.com/middleware/weblogic-operator:latest`.  This image can be deployed to a Kubernetes cluster.  It is recommended that the operator be deployed in its own namespace.  Only one operator is permitted in a namespace; however, multiple operators may be deployed in a Kubernetes cluster provided they are each in their own namespace and the list of namespaces they manage do not overlap.
 
-Scripts are provided to deploy the operator to a Kubernetes cluster.  These scripts also provide options to install and configure a load balancer, ELK integration and Prometheus integration.
+Scripts are provided to deploy the operator to a Kubernetes cluster.  These scripts also provide options to install and configure a load balancer and ELK integration.
 
 The operator registers a Kubernetes custom resource definition called `domain.weblogic.oracle` (shortname `domain`, plural `domains`).  
 
@@ -20,7 +20,6 @@ The Kubernetes cluster has several namespaces.  Components may be deployed into
 *	The operator is deployed into its own namespace.  If the ELK integration option is configured, then a logstash pod will also be deployed in the operator’s namespace.
 *	WebLogic domains will be deployed into various namespaces.  There can be more than one domain in a namespace if desired.  There is no limit on the number of domains or namespaces that an operator can manage.  Note that there can be more than one operator in a Kubernetes cluster, but each operator is configured with a list of the specific namespaces that it is responsible for.  The operator will not take any action on any domain that is not in one of the namespaces the operator is configured to manage.
 *	If the ELK integration option is configured, ElasticSearch and Kibana will be deployed in the `default` namespace.
-*	If the Prometheus integration option is configured, Prometheus and Grafana will be deployed in the `monitoring` namespace.
 *	If a load balancer is configured, it will be deployed in the `kube-system` namespace.
 
 ## Domain architecture
@@ -54,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

@@ -115,7 +115,6 @@ The following parameters must be provided in the input file:
 | loadBalancerAdminPort	| The node port for the load balancer to accept admin requests.	| 30315 |
 | loadBalancerWebPort	| The node port for the load balancer to accept user traffic. 	| 30305 |
 | enableLoadBalancerAdminPort	| Determines whether the load balancer administration port should be exposed outside the Kubernetes cluster.	| false |
-| enablePrometheusIntegration	| Determines whether the Prometheus integration will be enabled.  If set to ‘true’, then the WebLogic Monitoring Exporter will be installed on all servers in the domain and configured to export metrics to Prometheus. |	false |
 
 ## Limitations of the create domain script
 
@@ -222,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.
@@ -374,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/database.md

@@ -1,8 +1,6 @@
 # Running the Oracle Database in Kubernetes
 
-**ATTENTION EARLY ACCES USERS** this page is a work in progress.  We will update this with either better details about how to put the datafiles onto a persistent volume, or a pointer to the official Oracle Database Kubernetes pages, or both.
-
-write me
+**PLEASE NOTE** this page is a work in progress.  We will update this with either better details about how to put the datafiles onto a persistent volume, or a pointer to the official Oracle Database Kubernetes pages, or both.
 
 ```
 

site/developer.md

@@ -126,10 +126,6 @@ To create the Kuberentes YAML file to deploy the operator, update the inputs fil
 ```
 
 
-## Attaching a remote debugger to the operator
-
-Write me
-
 ## Coding standards
 
 This project has adopted the following coding standards:
@@ -152,7 +148,7 @@ This project has the following directory structure:
 * src/main/java: Java source code for the operator
 * src/test/java: Java unit-tests for the operator
 * src-generated-swagger: Snapshot of Java source files generated from the domain custom resource's swagger
-* swagger: Swagger files for Kubernetes API server and domain custom resource 
+* swagger: Swagger files for Kubernetes API server and domain custom resource
 
 ### Watch package
 

site/elk.md

@@ -1,6 +1,6 @@
 # ELK integration
 
-**ATTENTION EARLY ACCESS USERS** This page is not ready for general consumption yet, we have some rough notes in here, we are working on writing better doc for how to set up this integration.
+**PLEASE NOTE** This page is a work in progress, we have some rough notes in here, we are working on writing better doc for how to set up this integration.
 
 TODO Update this whole section
 Turn on Logstash in operator