Operator version 3.1.2

README.md

@@ -3,7 +3,7 @@
 Oracle is finding ways for organizations using WebLogic Server to run important workloads, to move those workloads into the cloud. By certifying on industry standards, such as Docker and Kubernetes, WebLogic now runs in a cloud neutral infrastructure. In addition, we've provided an open-source Oracle WebLogic Server Kubernetes Operator (the “operator”) which has several key features to assist you with deploying and managing WebLogic domains in a Kubernetes environment. You can:
 
 * Create WebLogic domains in a Kubernetes persistent volume. This persistent volume can reside in an NFS file system or other Kubernetes volume types.
-* Create a WebLogic domain in a Docker image.
+* Create a WebLogic domain in a container image.
 * Override certain aspects of the WebLogic domain configuration.
 * Define WebLogic domains as a Kubernetes resource (using a Kubernetes custom resource definition).
 * Start servers based on declarative startup parameters and desired states.
@@ -17,8 +17,8 @@ Oracle is finding ways for organizations using WebLogic Server to run important
 The fastest way to experience the operator is to follow the [Quick Start guide](https://oracle.github.io/weblogic-kubernetes-operator/quickstart/), or you can peruse our [documentation](https://oracle.github.io/weblogic-kubernetes-operator), read our [blogs](https://blogs.oracle.com/weblogicserver/updated-weblogic-kubernetes-support-with-operator-20), or try out the [samples](https://oracle.github.io/weblogic-kubernetes-operator/samples/).
 
 ***
-The [current release of the operator](https://github.com/oracle/weblogic-kubernetes-operator/releases) is 3.1.1.
-This release was published on December 17, 2020.
+The [current release of the operator](https://github.com/oracle/weblogic-kubernetes-operator/releases) is 3.1.2.
+This release was published on January 22, 2021.
 ***
 
 # Documentation

buildDockerImage.sh

@@ -1,17 +1,17 @@
 #!/bin/bash
-# Copyright (c) 2020, Oracle Corporation and/or its affiliates.
+# Copyright (c) 2020, 2021, Oracle and/or its affiliates.
 # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
 
 usage() {
 cat << EOF
 
 Usage: buildDockerImage.sh [-t tag]
-Builds a Docker Image for the Oracle WebLogic Kubernetes Operator.
+Builds a container image for the Oracle WebLogic Kubernetes Operator.
 
 Parameters:
    -t: image name and tag in 'name:tag' format
 
-Copyright (c) 2020, Oracle Corporation and/or its affiliates.
+Copyright (c) 2020, 2021, Oracle and/or its affiliates.
 Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
 
 EOF
@@ -33,7 +33,7 @@ while getopts "t:" optname; do
   esac
 done
 
-IMAGE_NAME=${name:-ghcr.io/oracle/weblogic-kubernetes-operator:3.1.1}
+IMAGE_NAME=${name:-ghcr.io/oracle/weblogic-kubernetes-operator:3.1.2}
 SCRIPTPATH="$( cd "$(dirname "$0")" > /dev/null 2>&1 ; pwd -P )"
 
 # Proxy settings
@@ -84,5 +84,5 @@ cat << EOF
 
 EOF
 else
-  echo "WebLogic Kubernetes Operator Docker Image was NOT successfully created. Check the output and correct any reported problems with the docker build operation."
+  echo "WebLogic Kubernetes Operator container image was NOT successfully created. Check the output and correct any reported problems with the docker build operation."
 fi

buildtime-reports/pom.xml

@@ -8,7 +8,7 @@
     <parent>
         <artifactId>operator-parent</artifactId>
         <groupId>oracle.kubernetes</groupId>
-        <version>3.1.1</version>
+        <version>3.1.2</version>
     </parent>
 
     <artifactId>buildtime-reports</artifactId>

docs-source/content/_index.md

@@ -3,7 +3,7 @@
 Oracle is finding ways for organizations using WebLogic Server to run important workloads, to move those workloads into the cloud. By certifying on industry standards, such as Docker and Kubernetes, WebLogic now runs in a cloud neutral infrastructure. In addition, we've provided an open source Oracle WebLogic Server Kubernetes Operator (the “operator”) which has several key features to assist you with deploying and managing WebLogic domains in a Kubernetes environment. You can:
 
 * Create WebLogic domains in a Kubernetes PersistentVolume. This PersistentVolume can reside in an NFS file system or other Kubernetes volume types.
-* Create a WebLogic domain in a Docker image.
+* Create a WebLogic domain in a container image.
 * Override certain aspects of the WebLogic domain configuration.
 * Define WebLogic domains as a Kubernetes resource (using a Kubernetes custom resource definition).
 * Start servers based on declarative startup parameters and desired states.
@@ -23,8 +23,8 @@ using the operator to deploy and run a WebLogic domain container-packaged web ap
 ***
 #### Current production release
 
-The [current release of the operator](https://github.com/oracle/weblogic-kubernetes-operator/releases) is 3.1.1.
-This release was published on December 17, 2020. See the operator prerequisites and supported environments [here]({{< relref "/userguide/introduction/introduction#operator-prerequisites" >}}).
+The [current release of the operator](https://github.com/oracle/weblogic-kubernetes-operator/releases) is 3.1.2.
+This release was published on January 22, 2021. See the operator prerequisites and supported environments [here]({{< relref "/userguide/introduction/introduction#operator-prerequisites" >}}).
 
 ***
 

docs-source/content/developerguide/building.md

@@ -28,13 +28,12 @@ $ mvn javadoc:aggregate
 
 The Javadoc is also available in the GitHub repository [here](https://oracle.github.io/weblogic-kubernetes-operator/apidocs/index.html).
 
-#### Building the operator Docker image
+#### Building the operator container image
 
-Log in to the Docker Store so that you will be able to pull the base image and create the Docker image as follows.  These commands should be executed in the project root directory:
+These commands should be executed in the project root directory:
 
 ```
-$ docker login
-$ docker build --build-arg VERSION=<version> -t weblogic-kubernetes-operator:some-tag --no-cache=true .
+$ ./buildDockerImage.sh -t weblogic-kubernetes-operator:some-tag
 ```
 
 Replace `<version>` with the version of the project found in the `pom.xml` file in the project root directory.
@@ -51,7 +50,7 @@ You may need to create a directory called `/operator` on your machine.  Please b
 
 #### Running the operator in a Kubernetes cluster
 
-If you're not running Kubernetes on your development machine, you'll need to make the Docker image available to a registry visible to your Kubernetes cluster.  Either `docker push` the image to a private registry or upload your image to a machine running Docker and Kubernetes as follows:
+If you're not running Kubernetes on your development machine, you'll need to make the container image available to a registry visible to your Kubernetes cluster.  Either `docker push` the image to a private registry or upload your image to a machine running Docker and Kubernetes as follows:
 
 ```
 # on your build machine

docs-source/content/developerguide/integration-tests.md

@@ -6,7 +6,7 @@ weight: 4
 ---
 
 
-The project includes integration tests that can be run against a Kubernetes cluster.  If you want to use these tests, you will need to provide your own Kubernetes cluster.  The Kubernetes cluster must meet the version number requirements and have Helm installed.  Ensure that the operator Docker image is in a Docker registry visible to the Kubernetes cluster.
+The project includes integration tests that can be run against a Kubernetes cluster.  If you want to use these tests, you will need to provide your own Kubernetes cluster.  The Kubernetes cluster must meet the version number requirements and have Helm installed.  Ensure that the operator container image is in a Docker registry visible to the Kubernetes cluster.
 
 
 You will need to obtain the `kube.config` file for an administrative user and make it available on the machine running the build.  To run the tests, update the `KUBECONFIG` environment variable to point to your config file and then execute:

docs-source/content/faq/cannot-pull-image.md

@@ -8,7 +8,7 @@ description: "My domain will not start and I see errors like `ImagePullBackoff`
 
 > My domain will not start and I see errors like `ImagePullBackoff` or `Cannot pull image`
 
-When you see these kinds of errors, it means that Kubernetes cannot find your Docker image.
+When you see these kinds of errors, it means that Kubernetes cannot find your container image.
 The most common causes are:
 
 * The `image` value in your Domain is set incorrectly, meaning Kubernetes will be
@@ -17,7 +17,7 @@ The most common causes are:
   configured Kubernetes with the necessary credentials, for example in an `imagePullSecret`.
 * You built the image on a machine that is not where your `kubelet` is running and Kubernetes
   cannot see the image, meaning you need to copy the image to the worker nodes or put it in
-  a Docker registry that is accessible the to all of the worker nodes.
+  a container registry that is accessible the to all of the worker nodes.
 
 Let's review what happens when Kubernetes starts a pod.
 
@@ -26,39 +26,39 @@ Let's review what happens when Kubernetes starts a pod.
 The definition of the pod contains a list of container specifications.  Each container
 specification contains the name (and optionally, tag) of the image that should be used
 to run that container.  In the example above, there is a container called `c1` which is
-configured to use the Docker image `some.registry.com/owner/domain1:1.0`.  This image
+configured to use the container image `some.registry.com/owner/domain1:1.0`.  This image
 name is in the format `registry address / owner / name : tag`, so in this case the
 registry is `some.registry.com`, the owner is `owner`, the image name is `domain`
 and the tag is `1.0`.  Tags are a lot like version numbers, but they are not required
 to be numbers or to be in any particular sequence or format.  If you omit the tag, it
 is assumed to be `latest`.
 
 {{% notice note %}}
-The Docker tag `latest` is confusing - it does not actually mean the latest version of
+The tag `latest` is confusing - it does not actually mean the latest version of
 the image that was created or published in the registry; it just literally means
 whichever version the owner decided to call "latest".  Docker and Kubernetes make
 some assumptions about latest, and it is generally recommended to avoid using it and instead
 specify the actual version or tag that you really want.
 {{% /notice %}}
 
 First, Kubernetes will check to see if the requested image is available in the local
-Docker image store on whichever worker node the pod was scheduled on.  If it is there,
+container image store on whichever worker node the pod was scheduled on.  If it is there,
 then it will use that image to start the container.  If it is not there, then Kubernetes
-will attempt to pull the image from a remote Docker registry.
+will attempt to pull the image from a remote container registry.
 
 {{% notice note %}}
 There is another setting called `imagePullPolicy` that can be used to force Kubernetes
-to always pull the image, even if it is already present in the local Docker image
+to always pull the image, even if it is already present in the local container image
 store.
 {{% /notice %}}
 
 If the image is available in the remote registry and it is public, that is it does not
-require authentication, then Kubernetes will pull the image to the local Docker image
+require authentication, then Kubernetes will pull the image to the local container image
 store and start the container.
 
 #### Images that require authentication
 
-If the remote Docker registry requires authentication, then you will need to provide
+If the remote container registry requires authentication, then you will need to provide
 the authentication details in a Kubernetes `docker-registry` secret and tell Kubernetes
 to use that secret when pulling the image.
 
@@ -76,7 +76,7 @@ kubectl create secret docker-registry secret1 \
 In this command, you would replace `secret1` with the name of the secret; the `docker-server`
 is set to the registry name, without the `https://` prefix; the `docker-username`, `docker-password`
 and `docker-email` are set to match the credentials you use to authenticate to the remote
-Docker registry; and the `namespace` must be set to the same namespace where you intend to
+container registry; and the `namespace` must be set to the same namespace where you intend to
 use the image.
 
 {{% notice note %}}
@@ -122,9 +122,9 @@ kubectl patch serviceaccount default \
 ```
 
 {{% notice note %}}
-You can provide multiple `imagePullSecrets` if you need to pull Docker images from multiple
-remote Docker registries or if your images require different authentication credentials.
-For more information, see [Docker Image Protection]({{<relref "/security/domain-security/image-protection#weblogic-domain-in-docker-image-protection">}}).
+You can provide multiple `imagePullSecrets` if you need to pull container images from multiple
+remote container registries or if your images require different authentication credentials.
+For more information, see [Container Image Protection]({{<relref "/security/domain-security/image-protection#weblogic-domain-in-container-image-protection">}}).
 {{% /notice %}}
 
 #### Pushing the image to a repository
@@ -151,8 +151,8 @@ a remote repository, then the Docker steps are:
 
 #### Manually copying the image to your worker nodes
 
-If you are not able to use a remote Docker registry, for example if your Kubernetes cluster is
-in a secure network with no external access, then you can manually copy the Docker images to the
+If you are not able to use a remote container registry, for example if your Kubernetes cluster is
+in a secure network with no external access, then you can manually copy the container images to the
 cluster instead.
 
 On the machine where you created the image, export it into a TAR file using this command:

docs-source/content/faq/domain-secret-mismatch.md

@@ -32,28 +32,28 @@ This can happen in a variety of ways, depending on the [domain home source type]
 
 ##### Rolling to an image containing new or unrelated domain directory
 
-The error occurs while rolling pods have containers based on a new Docker image that contains an entirely new or unrelated domain directory.
+The error occurs while rolling pods have containers based on a new container image that contains an entirely new or unrelated domain directory.
 
 The problem is that WebLogic cannot support server instances being part of the same WebLogic domain if the server instances do
 not all share the same domain-specific encryption key. Additionally, operator introspection
 currently happens only when starting servers following a total shutdown. Therefore, the `boot.properites` files generated from
 introspecting the image containing the original domain directory will be invalid when used with a container started with
-the updated Docker image containing the new or unrelated domain directory.
+the updated container image containing the new or unrelated domain directory.
 
-The solution is to follow either the recommended [CI/CD guidelines](https://oracle.github.io/weblogic-kubernetes-operator/userguide/cicd/) so that the original and new Docker images contain domain directories
+The solution is to follow either the recommended [CI/CD guidelines](https://oracle.github.io/weblogic-kubernetes-operator/userguide/cicd/) so that the original and new container images contain domain directories
 with consistent domain-specific encryption keys and bootstrapping security details, or to [perform a total shutdown](https://oracle.github.io/weblogic-kubernetes-operator/userguide/managing-domains/domain-lifecycle/startup/#starting-and-stopping-servers) of the domain so
 that introspection reoccurs as servers are restarted.
 
 ##### Full domain shutdown and restart
 
 The error occurs while starting servers after a full domain shutdown.
 
-If your development model generates new Docker images
+If your development model generates new container images
 with new and unrelated domain directories and then tags those images with the same tag, then different Kubernetes worker nodes
-may have different images under the same tag in their individual, local Docker repositories.
+may have different images under the same tag in their individual, local container repositories.
 
 The simplest solution is to set `imagePullPolicy` to `Always`; however, the better solution would be to design your development
-pipeline to generate new Docker image tags on every build and to never reuse an existing tag.
+pipeline to generate new container image tags on every build and to never reuse an existing tag.
 
 #### Domain in PV
 
@@ -67,4 +67,4 @@ Because all servers will already be stopped, there is no requirement that the ne
 the previous contents of the domain directory.  When starting servers again, the operator will perform its introspection
 of the domain directory. However, you may want to preserve the domain directory security configuration including the domain-specific
 encryption key and, in that case, you should follow a similar pattern as is described in the [CI/CD guidelines](https://oracle.github.io/weblogic-kubernetes-operator/userguide/cicd/) for the domain
-in a Docker image model to preserve the original security-related domain directory files.
+in a container image model to preserve the original security-related domain directory files.

docs-source/content/faq/namespace-management.md

@@ -43,7 +43,7 @@ elkIntegrationEnabled: false
 externalDebugHttpPort: 30999
 externalRestEnabled: false
 externalRestHttpsPort: 31001
-image: ghcr.io/oracle/weblogic-kubernetes-operator:3.1.1
+image: ghcr.io/oracle/weblogic-kubernetes-operator:3.1.2
 imagePullPolicy: IfNotPresent
 internalDebugHttpPort: 30999
 istioEnabled: false