Merge pull request #6786 from OpenLiberty/staging

Staging to vNext, 23.0.0.7 issues

modules/ROOT/pages/instanton.adoc

@@ -84,9 +84,15 @@ Unprivileged (non-root) users are supported by CRIU for checkpointing and restor
 
 To perform an application process checkpoint, CRIU requires the following Linux capabilities:
 
-- `CHECKPOINT_RESTORE` - This capability was added in Linux 5.9 to separate checkpoint/restore functions from the overloaded SYS_ADMIN capability.
-- `SETPCAP` - Allows CRIU to drop capabilities from the restored application process. Because the CRIU binary is granted more capabilities, like `CHECKPOINT_RESTORE`, it needs these capabilities so it can drop such capabilities from the final process that CRIU restored.
-- `SYS_PTRACE` - A powerful capability needed by CRIU to be able to capture and record the full process state. This capability is necessary only when CRIU is checkpointing an application process. For the restore process, only the `CHECKPOINT_RESTORE` and `SETPCAP` capabilities are necessary.
+- `CHECKPOINT_RESTORE` - This capability was added in Linux 5.9 to separate checkpoint/restore functions from the overloaded `SYS_ADMIN` capability.
+- `SETPCAP` - This capability is required for the subsequent restore. 
+- `SYS_PTRACE` - CRIU uses this powerful capability to capture and record the full process state. It is necessary only when CRIU is checkpointing an application process. 
+
+To perform an application process restore, CRIU requires the following Linux capabilities:
+
+- `CHECKPOINT_RESTORE` - This capability was added in Linux 5.9 to separate checkpoint/restore functions from the overloaded `SYS_ADMIN` capability.
+- `SETPCAP` - This capability allows CRIU to drop capabilities from the restored application process. Because the CRIU binary is granted extra capabilities like `CHECKPOINT_RESTORE`, it needs `SETPCAP` so it can drop those capabilities from the final process that CRIU restores.
+
 
 [#build]
 == Building an InstantOn application image

modules/ROOT/pages/open-liberty-operator.adoc

@@ -27,7 +27,7 @@ Now, you manage only a single `OpenLibertyApplication` resource instead of many
 In addition, the operator continuously monitors the events that are related to the application in the cluster and takes necessary actions to synchronize data and resources.
 Because the operator helps you manage Kubernetes resources, you can focus on your application while the operator handles many of the cloud deployment details.
 
-The Open Liberty Operator is based on the https://operatorhub.io/operator/runtime-component-operator[Runtime Component Operator], which is a generic operator that can be imported into runtime-specific operators to provide standardized enterprise capabilities.
+The Open Liberty Operator is based on the https://github.com/application-stacks/runtime-component-operator/blob/main/doc/user-guide-v1.adoc[Runtime Component Operator], which is a generic operator that can be imported into runtime-specific operators to provide standardized enterprise capabilities.
 As such, common functionality exists between these two operators, such as the use of image streams and the ability to run multiple instances of your application for high availability.
 When you use the Open Liberty Operator, the operator container and controller are deployed to a Kubernetes pod, and the operator listens for incoming resources with the `kind: OpenLibertyApplication` statement.
 When you create an `OpenLibertyApplication` custom resource (CR), the operator manages the Kubernetes resources that the application needs to run on your cluster.
@@ -44,7 +44,7 @@ This ability to run multiple instances of your application and auto-scale them m
 * **Enhanced deployment management**
 +
 With the Open Liberty Operator, you can more easily manage applications that are deployed to Kubernetes.
-For example, in the operator deployment file, you can specify an https://docs.openshift.com/container-platform/3.9/architecture/core_concepts/builds_and_image_streams.html#image-streams[image stream] in the `applicationImage` field.
+For example, in the operator deployment file, you can specify an https://docs.openshift.com/container-platform/latest/openshift_images/image-streams-manage.html[image stream] in the `applicationImage` field.
 Then, after you upload a new container tag for a new version of an application, the operator updates the application on a rolling basis.
 
 * **Automated service binding**
@@ -71,11 +71,11 @@ Certificates are mounted into containers from a Kubernetes Secret so that the ce
 
 
 == Serviceability and observability with the Open Liberty Operator
-You can https://github.com/application-stacks/runtime-component-operator/blob/main/doc/user-guide.adoc#persistence[enable persistence for your application] by specifying only the size of storage and where you want the storage to be mounted.
+You can https://github.com/OpenLiberty/open-liberty-operator/blob/main/doc/user-guide-v1.adoc#persist-resources[enable persistence for your application] by specifying only the size of storage and where you want the storage to be mounted.
 Then, the operator creates and manages the storage claim for you.
 An advanced mode is available that allows the configuration of extra details of the persistent volume claim.
 You can also configure and use a single storage for serviceability-related operations, such as gathering server memory dumps and server traces.
-For more information about gathering server memory dumps and server traces, see https://github.com/OpenLiberty/open-liberty-operator/blob/main/doc/user-guide.adoc#day-2-operations[Day-2 operations].
+For more information about gathering server memory dumps and server traces, see https://github.com/OpenLiberty/open-liberty-operator/blob/main/doc/user-guide-v1.adoc#day-2-operations[Day-2 operations].
 
 After you configure the operator, you can https://github.com/OpenLiberty/open-liberty-operator/blob/main/doc/observability-deployment.adoc[integrate Open Liberty with logging and monitoring tools for observability] in the Kubernetes cluster.
 You can select different types of Open Liberty data that you want to monitor.
@@ -84,9 +84,7 @@ You can monitor Open Liberty metrics by using MicroProfile Metrics, Prometheus,
 You can also enable MicroProfile Health to perform liveness checks and readiness checks so that Kubernetes can check the health of your containers.
 
 == Operator installation and configuration
-You can https://operatorhub.io/operator/open-liberty[install the Open Liberty Operator from OperatorHub] for use on Kubernetes or OpenShift.
-The https://access.redhat.com/containers/#/registry.connect.redhat.com/ibm/open-liberty-operator[operator is also available as a Red Hat-certified operator] from OpenShift Container Platform (OCP).
-The Open Liberty Operator documentation provides details about configuring the operator, including basic configuration, Custom Resource Definition (CRD) parameters, Open Liberty console logging environment variables, and persistent storage specifications.
+You can install the Open Liberty Operator from the integrated OperatorHub on OpenShift. On other Kubernetes platforms, install the Open Liberty Operator by using `_kustomize_` or `_kubectl_`. The Open Liberty Operator https://ibm.biz/olo-docs[documentation] provides details about Operator capabilities, installation, Custom Resource Definition (CRD) parameters and basic or advanced configurations.
 
 
 == See also

modules/reference/pages/config/server-configuration-overview.adoc

@@ -39,6 +39,7 @@ If it's not clear in context, the term _server XML configuration_ might be used
 The following sections provide more details on configuring a server.
 
 * <<#configuration-files,Configuration files>>
+* <<#variable-syntax,Configuration variable syntax>>
 * <<#variable-substitution,Variable substitution precedence>>
 * <<#configuration-merging,Configuration merging>>
 * <<#include-processing,Include processing>>
@@ -216,6 +217,18 @@ The `${server.config.dir}/server.xml` file must be present, but the other files
 You can flexibly compose configuration by dropping server-formatted XML files into directories.
 Files are read in alphabetical order in each of the two `configDropins` directories.
 
+
+[#variable-syntax]
+== Configuration variable syntax
+
+Variables define reusable values that are substituted with actual values at runtime. 
+In Open Liberty server configuration files, you can reference variables by using the `${variable.name}` syntax. The dollar sign (`$`) indicates the start of a variable reference. Curly brackets (`{}`) enclose the name of the variable.
+
+For example, if you define a variable that is named `database.url` with the value `jdbc:mysql://localhost:3306/mydb`, you can reference it in your server configuration files by using `${database.url}`. At runtime, Open Liberty replaces `${database.url}` with the actual value `jdbc:mysql://localhost:3306/mydb`.
+
+For more information about specifying variables, see <<#variable-substitution,Variable substitution precedence>>.
+
+
 [#variable-substitution]
 == Variable substitution precedence
 You can use variables to parameterize the server configuration.