You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs-source/content/developerguide/building.md
+1-5Lines changed: 1 addition & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,11 +16,7 @@ $ mvn clean install
16
16
17
17
This will compile the source files, build JAR files containing the compiled classes and libraries needed to run the operator, and will also execute all of the unit tests.
18
18
19
-
Contributions must conform to [coding and formatting standards]({{< relref "/developerguide/coding-standards.md" >}}). To automatically update local code to conform to formatting standards, issue the following command:
20
-
21
-
```
22
-
$ mvn fmt:format
23
-
```
19
+
Contributions must conform to [coding and formatting standards]({{< relref "/developerguide/coding-standards.md" >}}).
For more details on acquiring the operator image and prerequisites for installing the operator, consult the [Quick Start guide]({{< relref "/quickstart/_index.md" >}}).
Copy file name to clipboardExpand all lines: docs-source/content/userguide/managing-domains/configoverrides/_index.md
+17-4Lines changed: 17 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -336,7 +336,12 @@ spec:
336
336
---
337
337
### Debugging
338
338
339
-
Incorrectly formatted override files may be accepted without warnings or errors and will not prevent WebLogic pods from booting. So, it is important to make sure that the template files are correct in a QA environment, otherwise your WebLogic Servers may start even though critically required overrides are failing to take effect.
339
+
Incorrectly formatted override files may be accepted without warnings or errors and may not prevent WebLogic pods from booting. So, it is important to make sure that the template files are correct in a QA environment, otherwise your WebLogic Servers may start even though critically required overrides are failing to take effect.
340
+
341
+
On WebLogic Servers that support the `weblogic.SituationalConfig.failBootOnError` system property ( Note: It is not supported in WebLogic Server 12.2.1.3.0 ),
342
+
by default the WebLogic server will fail to boot if any situational configuration files are invalid,
343
+
or if it encounters an error while loading situational configuration files.
344
+
By setting the `FAIL_BOOT_ON_SITUATIONAL_CONFIG_ERROR` environment variable in the Kubernetes containers for the WebLogic Servers to `false`, you can start up the WebLogic Servers even with incorrectly formatted override files.
340
345
341
346
* Make sure you've followed each step in the [Step-by-step guide](#step-by-step-guide).
342
347
@@ -363,9 +368,17 @@ Incorrectly formatted override files may be accepted without warnings or errors
363
368
...
364
369
```
365
370
* Look in your `DOMAIN_HOME/optconfig` directory.
366
-
* This directory, or a subdirectory within this directory, should contain each of your custom situational configuration files.
367
-
* If it doesn't, then this likely indicates your domain resource `configOverrides` was not set to match your custom override configuration map name, or that your custom override configuration map does not contain your override files.
368
-
371
+
* This directory, or a subdirectory within this directory, should contain each of your custom situational configuration files.
372
+
* If it doesn't, then this likely indicates your domain resource `configOverrides` was not set to match your custom override configuration map name, or that your custom override configuration map does not contain your override files.
373
+
374
+
* If the Administration Server pod does start but fails to reach ready state or tries to restart:
375
+
* Check for this message ` WebLogic server failed to start due to missing or invalid situational configuration files` in the Administration Server pod's `kubectl log`
376
+
* This suggests that the Administration Server failure to start may have been caused by errors found in a configuration override file.
377
+
* Lines containing the String `situational` may be found in the Administration Server pod log to provide more hints.
378
+
* For example:
379
+
* `<Jun 20, 2019 3:48:45 AM GMT> <Warning> <Management> <BEA-141323> <The situational config file has an invalid format, it is being ignored: XMLSituationalConfigFile[/shared/domains/domain1/optconfig/jdbc/testDS-0527-jdbc-situational-config.xml] because org.xml.sax.SAXParseException; lineNumber: 8; columnNumber: 3; The element type "jdbc:jdbc-driver-params" must be terminated by the matching end-tag "</jdbc:jdbc-driver-params>".`
380
+
* The warning message suggests a syntax error is found in the provided configuration override file for the testDS JDBC datasource.
381
+
369
382
* If you'd like to verify that the situational configuration is taking effect in the WebLogic MBean tree, then one way to do this is to compare the `server config` and `domain config` MBean tree values.
370
383
* The `domain config` value should reflect the original value in your domain home configuration.
371
384
* The `server config` value should reflect the overridden value.
Copy file name to clipboardExpand all lines: docs-source/content/userguide/managing-domains/domain-resource.md
+66-1Lines changed: 66 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,9 @@ pre = "<b> </b>"
8
8
9
9
10
10
11
-
Use this document to set up and configure your own [domain resource](https://github.com/oracle/weblogic-kubernetes-operator/blob/master/docs/domains/Domain.md) which can be used to configure your WLS domain. Then, you can use the domain resource to start the Kubernetes artifacts of the corresponding domain.
11
+
Use this document to set up and configure your own [domain resource](https://github.com/oracle/weblogic-kubernetes-operator/blob/master/docs/domains/Domain.md) which can be used to configure the operation of your WebLogic domain. The domain resource does not replace the traditional configuration of WebLogic domains found in the domain configuration files, but instead cooperates with those files to describe the Kubernetes artifacts of the corresponding domain. For instance, the WebLogic domain configuration will still specify deployed applications, data sources, and most other details about the domain while the domain resource will specify the number of cluster members currently running or the persistent volumes that will be mounted into the containers running WebLogic Server instances.
12
+
13
+
Many of the samples accompanying the operator project include scripts to generate an initial domain resource from a set of simplified inputs; however, the domain resource is the actual source of truth for how the WebLogic operator will manage each WebLogic domain. You are encouraged to either start with the domain resource YAML files generated by the various samples or create domain resources manually or by using other tools based on the schema referenced here or this documentation.
12
14
13
15
Swagger documentation is available [here](https://oracle.github.io/weblogic-kubernetes-operator/swagger/index.html).
14
16
@@ -41,3 +43,66 @@ To confirm that the domain resource was created, use this command:
The domain resource, like all [Kubernetes objects](https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/), is described by three sections: `metadata`, `spec`, and `status`.
50
+
51
+
The `metadata` section names the domain resource and its namespace. The name of the domain resource is the default value for the "domain UID" which is used by the operator to distinguish domains running in the Kubernetes cluster that may have the same domain name. The domain resource name is required to be unique in the namespace and the domain UID should be unique across the cluster. The domain UID, domain resource name, and domain name (from the WebLogic domain configuration) may all be different.
52
+
53
+
The `spec` section describes the intended running state of the domain, including intended runtime state of server instances, number of cluster members started, and details about Kubernetes pod or service generation, such as resource constraints, scheduling requirements, or volume mounts.
54
+
55
+
The `status` section is updated by the operator and describes the actual running state of the domain, including WebLogic Server instance runtime states and current health.
56
+
57
+
#### Domain resource spec elements
58
+
59
+
The domain resource `spec` section contains elements for configuring the domain operation and sub-sections specific to the Administration Server, specific clusters or specific Managed Servers.
60
+
61
+
Elements related to domain identification, Docker image, and domain home:
62
+
*`domainUID`: The domain unique identifier. Must be unique across the Kubernetes cluster. Not required. Defaults to the value of `metadata.name`.
63
+
*`image`: The WebLogic Docker image. Required when `domainHomeInImage` is true; otherwise, defaults to "container-registry.oracle.com/middleware/weblogic:12.2.1.3".
64
+
*`imagePullPolicy`: The image pull policy for the WebLogic Docker image. Legal values are `Always`, `Never` and `IfNotPresent`. Defaults to `Always` if image ends in ":latest", `IfNotPresent` otherwise.
65
+
*`imagePullSecrets`: A list of image pull secrets for the WebLogic Docker image.
66
+
*`domainHome`: The folder for the WebLogic Domain. Not required. Defaults to "/shared/domains/domains/domainUID" if `domainHomeInImage` is false. Defaults to "/u01/oracle/user_projects/domains/" if `domainHomeInImage` is true.
67
+
*`domainHomeInImage`: True if this domain's home is defined in the Docker image for the domain. Defaults to true.
68
+
69
+
Elements related to logging:
70
+
*`includeServerOutInPodLog`: If true (the default), the server ".out" file will be included in the pod's stdout.
71
+
*`logHome`: The in-pod name of the directory in which to store the domain, Node Manager, server logs, and server ".out" files.
72
+
*`logHomeEnabled`: Specifies whether the log home folder is enabled. Not required. Defaults to true if `domainHomeInImage` is false. Defaults to false if `domainHomeInImage` is true.
73
+
74
+
Elements related to security:
75
+
*`webLogicCredentialsSecret`: The name of a pre-created Kubernetes secret, in the domain resource's namespace, that holds the user name and password needed to boot WebLogic Server under the 'username' and 'password' fields.
76
+
77
+
Elements related to domain [startup and shutdown](domain-lifecycle/startup.md):
78
+
*`serverStartPolicy`: The strategy for deciding whether to start a server. Legal values are `ADMIN_ONLY`, `NEVER`, or `IF_NEEDED`.
79
+
*`serverStartState`: The state in which the server is to be started. Use `ADMIN` if server should start in the admin state. Defaults to `RUNNING`.
80
+
*`restartVersion`: If present, every time this value is updated, the operator will restart the required servers.
81
+
*`replicas`: The number of Managed Servers to run in any cluster that does not specify a `replicas` count.
82
+
83
+
Elements related to overriding WebLogic domain configuration:
84
+
*`configOverrides`: The name of the config map for optional WebLogic configuration overrides.
85
+
*`configOverrideSecrets`: A list of names of the secrets for optional WebLogic configuration overrides.
86
+
87
+
Elements related to Kubernetes pod and service generation:
88
+
*`serverPod`: Configuration affecting server pods.
89
+
*`serverService`: Customization affecting ClusterIP Kubernetes services for WebLogic Server instances.
90
+
91
+
Sub-sections related to the Administration Server, specific clusters or specific Managed Servers:
92
+
*`adminServer`: Configuration for the Administration Server.
93
+
*`clusters`: Configuration for specific clusters.
94
+
*`managedServers`: Configuration for specific Managed Servers.
95
+
96
+
The elements `serverStartPolicy`, `serverStartState`, `serverPod` and `serverService` are repeated under `adminServer` and under each entry of `clusters` or `managedServers`. The values directly under `spec` set the defaults for the entire domain. The values under a specific entry under `clusters` set the defaults for cluster members of that cluster. The values under `adminServer` or an entry under `managedServers` set the values for that specific server. Values from the domain scope and values from the cluster (for cluster members) are merged with or overridden by the setting for the specific server depending on the element. See the [startup and shutdown](domain-lifecycle/startup.md) documentation for details about `serverStartPolicy` combination.
97
+
98
+
### Pod generation
99
+
100
+
The operator creates a pod for each running WebLogic Server instance. This pod will have a container based on the Docker image specified by the `image` field. Additional pod or container content can be specified using the elements under `serverPod`. This includes Kubernetes labels and annotations, additional volumes on the pod or volume mounts on the container, [resource requirements](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) or [security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).
101
+
102
+
Prior to creating a pod, the operator replaces variable references allowing the pod content to be templates. The format of these variable references is `$(VARIABLE_NAME)` where *VARIABLE_NAME* is one of the variable names available in the container for the WebLogic Server instance. The default set of environment variables includes:
103
+
* DOMAIN_NAME: The WebLogic domain name
104
+
* DOMAIN_UID: The domain unique identifier
105
+
* DOMAIN_HOME: The domain home location as a file system path within the container
106
+
* SERVER_NAME: The WebLogic Server name
107
+
* CLUSTER_NAME: The WebLogic cluster name, if this is a cluster member
108
+
* LOG_HOME: The WebLogic log location as a file system path within the container
Copy file name to clipboardExpand all lines: docs-source/content/userguide/managing-operators/using-the-operator/using-helm.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -101,7 +101,7 @@ javaLoggingLevel: "FINE"
101
101
102
102
Specifies the Docker image containing the operator code.
103
103
104
-
Defaults to `weblogic-kubernetes-operator:2.2.0`.
104
+
Defaults to `weblogic-kubernetes-operator:2.2.1`.
105
105
106
106
Example:
107
107
```
@@ -119,7 +119,7 @@ image: "Always"
119
119
```
120
120
121
121
##### `imagePullSecrets`
122
-
Contains an optional list of Kubernetes secrets, in the operator's namepace, that are needed to access the registry containing the operator Docker image. You are responsible for creating the secret. If no secrets are required, then omit this property.
122
+
Contains an optional list of Kubernetes secrets, in the operator's namespace, that are needed to access the registry containing the operator Docker image. You are responsible for creating the secret. If no secrets are required, then omit this property.
0 commit comments