Update 4
This use case demonstrates dynamically changing the Work Manager threads constraint and data source configuration in your running domain without restarting (rolling) running WebLogic Servers. This use case requires that the Update 1 use case has been run and expects that its sample-domain1 domain is deployed and running.
In the use case, you will:
- Update the ConfigMap containing the WDT model created in the Update 1 use case with changes to the Work Manager threads constraint configuration.
- Update the data source secret created in the Update 1 use case to provide the correct password and an increased maximum pool capacity.
- Update the Domain YAML file to enable the Model in Image online update feature.
- Update the Domain YAML file to trigger a domain introspection, which applies the new configuration values without restarting servers.
- Optionally, start a database (to demonstrate that the updated data source attributes have taken effect).
Here are the steps:
-
Make sure that you have deployed the domain from the Update 1 use case, or have deployed an updated version of this same domain from the Update 3 use case.
There should be three WebLogic Server pods with names that start with
sample-domain1running in thesample-domain1-nsnamespace, a domain namedsample-domain1, a ConfigMap namedsample-domain1-wdt-config-map, and a Secret namedsample-domain1-datasource-secret. -
Add the Work Manager threads constraint configuration WDT model updates to the existing data source model updates in the Model in Image model ConfigMap.
In this step, we will update the model ConfigMap from the Update 1 use case with the desired changes to the minimum and maximum threads constraints.
Here’s an example model configuration that updates the configured count values for the
SampleMinThreadsminimum threads constraint andSampleMaxThreadsmaximum threads constraint:Optionally, place the preceding model snippet in a file named
/tmp/sample/myworkmanager.yamland then use it when deploying the updated model ConfigMap, or simply use the same model snippet that’s provided in/tmp/sample/model-configmaps/workmanager/model.20.workmanager.yaml.Run the following commands:
Notes:
- If you’ve created your own model YAML file(s), then substitute the file names in the
--from-file=parameters (we suggested/tmp/sample/myworkmanager.yamland/tmp/sample/mydatasource.xmlearlier). - The
-from-file=parameter can reference a single file, in which case it puts the designated file in the ConfigMap, or it can reference a directory, in which case it populates the ConfigMap with all of the files in the designated directory. It can be specified multiple times on the same command line to load the contents from multiple locations into the ConfigMap. - You name and label the ConfigMap using its associated domain UID for two reasons:
- To make it obvious which ConfigMap belong to which domains.
- To make it easier to clean up a domain. Typical cleanup scripts use the
weblogic.domainUIDlabel as a convenience for finding all resources associated with a domain.
- If you’ve created your own model YAML file(s), then substitute the file names in the
-
Update the data source secret that you created in the Update 1 use case with the correct password as well as with an increased maximum pool capacity:
NOTE: Replace MY_ORACLE_SYS_PASSWORD with the same database
sysaccount password that you chose (or plan to choose) when deploying the database. -
Update your Domain YAML file to enable
onlineUpdate.If
onlineUpdateis enabled for your domain and the only model changes are to WebLogic Domain dynamic attributes, then the operator will attempt to update the running domains online without restarting the servers when you update the domain’sintrospectVersion.-
Option 1: Edit your domain custom resource.
- Call
kubectl -n sample-domain1-ns edit domain sample-domain1. - Add or edit the value of the
spec.configuration.model.onlineUpdatestanza so it containsenabled: trueand save. - The updated domain should look something like this:
- Call
-
Option 2: Dynamically change your domain using
kubectl patch. For example: -
Option 3: Use the sample helper script.
- Call
/tmp/sample/utils/patch-enable-online-update.sh -n sample-domain1-ns -d sample-domain1. - This will perform the same
kubectl patchcommands as Option 2.
- Call
-
-
Prompt the operator to introspect the updated WebLogic domain configuration.
Now that the updated Work Manager configuration is deployed in an updated model ConfigMap and the updated data source configuration is reflected in the updated data source Secret, we need to have the operator rerun its introspector job to regenerate its configuration.
Change the
spec.introspectVersionof the domain to trigger domain introspection. To do this:-
Option 1: Edit your domain custom resource.
- Call
kubectl -n sample-domain1-ns edit domain sample-domain1. - Change the value of the
spec.introspectVersionfield and save. - The field is a string; typically, you use a number in this field and increment it.
- Call
-
Option 2: Dynamically change your domain using
kubectl patch.-
Get the current
introspectVersion: -
Choose a new introspect version that’s different from the current introspect version.
- The field is a string; typically, you use a number in this field and increment it.
-
Use
kubectl patchto set the new value. For example, assuming the new introspect version is2:
-
-
Option 3: Use the sample helper script.
- Call
/tmp/sample/utils/patch-introspect-version.sh -n sample-domain1-ns -d sample-domain1. - This will perform the same
kubectl patchcommand as Option 2.
- Call
Because we have set the
enabledvalue inspec.configuration.model.onlineUpdatetotrue, and all of the model changes we have specified are for WebLogic dynamic configuration attributes, we expect that the domain introspector job will apply the changes to the WebLogic Servers without restarting (rolling) their pods. -
-
Wait for the introspector job to run to completion. You can:
-
Call
kubectl get pods -n sample-domain1-ns --watchand wait for the introspector pod to get intoTerminatingstate and exit. -
For a more detailed view of this activity, you can use the
waitForDomain.shsample lifecycle script. This script provides useful information about a domain’s pods and optionally waits for itsCompletedstatus condition to becomeTrue. ACompleteddomain indicates that all of its expected pods have reached areadystate plus their targetrestartVersion,introspectVersion, andimage. For example: -
If the introspector job fails, then consult Debugging .
-
-
Call the sample web application to:
- Determine if the configuration of the minimum and maximum threads constraints have been updated to the new values.
- Determine if the data source can now contact the database (assuming you deployed the database).
Send a web application request to the ingress controller:
Or, if Traefik is unavailable and your Administration Server pod is running, you can run
kubectl exec:You will see something like the following:
The testPool='Passed' for mynewdatasource verifies that your update to the data source Secret to correct the password succeeded.
If you see a testPool='Failed' error, then it is likely you did not deploy the database or your database is not deployed correctly.
If you see any other error, then consult Debugging .
This completes the sample scenarios.
To remove the resources you have created in the samples, see Cleanup .