Chapter 2. What is new in the JWS Operator 2.0 release? The JWS Operator 2.0 release provides level-2 Operator capabilities such as seamless integration. JWS Operator 2.0 also supports Red Hat JBoss Web Server metering labels and includes some enhanced Custom Resource Definition (CRD) parameters. Level-2 Operator capabilities JWS Operator 2.0 provides the following level-2 Operator capability features: Enables seamless upgrades Supports patch and minor version upgrades Manages web servers deployed by the JWS Operator 1.1.x. Enabling level-2 seamless integration for new images The DeploymentConfig object definition includes a trigger that OpenShift uses to deploy new pods when a new image is pushed to the image stream. The image stream can monitor the repository for new images or you can instruct the image stream that a new image is available for use. Procedure In your project namespace, create an image stream by using the oc import-image command to import the tag and other information for an image. For example: In the preceding example, replace each occurrence of <my-image> with the name of the image that you want to import. The preceding command creates an image stream named <my-image> -imagestream by importing information for the quay.io/USDuser/ <my-image> image. For more information about the format and management of image streams, see Managing image streams . Create a custom resource of the WebServer kind for the web application that you want the JWS Operator to deploy whenever the image stream is updated. You can define the custom resource in YAML file format. For example: Trigger an update to the image stream by using the oc tag command. For example: The preceding command causes OpenShift Container Platform to update the specified image stream tag periodically. This period is a cluster-wide setting that is set to 15 minutes by default. Level-2 seamless integration for rebuilding existing images The BuildConfig object definition includes a trigger for image stream updates and a webhook, which is either a GitHub or Generic webhook, that enables the rebuilding of images when the webhook is triggered by Git or GitHub. For more information about creating a secret for a webhook, see Creating a secret for a generic or GitHub webhook . For more information about configuring a generic or GitHub webhook in a custom resource WebServer file, see JWS Operator CRD parameters . Support for Red Hat JBoss Web Server metering labels JWS Operator 2.0 supports the ability to add metering labels to the Red Hat JBoss Web Server pods that the JWS Operator creates. Red Hat JBoss Web Server can use the following metering labels: com.company: Red_Hat rht.prod_name: Red_Hat_Runtimes rht.prod_ver: 2023-Q4 rht.comp: JBoss_Web_Server rht.comp_ver: 6.0.0 rht.subcomp: Tomcat 10 rht.subcomp_t: application You can add labels under the metadata section in the custom resource WebServer file for a web application that you want to deploy. For example: --- apiVersion: web.servers.org/v1alpha1 kind: WebServer metadata: name: <my-image> labels: com.company: Red_Hat rht.prod_name: Red_Hat_Runtimes rht.prod_ver: 2023-Q4 rht.comp: JBoss_Web_Server rht.comp_ver: 6.0.0 rht.subcomp: Tomcat 10 rht.subcomp_t: application spec: ---- Note If you change any label key or label value for a deployed web server, the JWS Operator redeploys the web server application. If the deployed web server was built from source code, the JWS Operator also rebuilds the web server application. Enhanced webImage parameter In the JWS Operator 2.0 release, the webImage parameter in the CRD contains the following additional fields: imagePullSecret The secret that the JWS Operator uses to pull images from the repository Note The secret must contain the key .dockerconfigjson . The JWS Operator mounts and uses the secret (for example, --authfile /mount_point/.dockerconfigjson ) to pull the images from the repository. The Secret object definition file might contain server username and password values or tokens to allow access to images in the image stream, the builder image, and images built by the JWS Operator. webApp A set of parameters that describe how the JWS Operator builds the web server application Enhanced webApp parameter In the JWS Operator 2.0 release, the webApp parameter in the CRD contains the following additional fields: name The name of the web server application sourceRepositoryURL The URL where the application source files are located sourceRepositoryRef The branch of the source repository that the Operator uses sourceRepositoryContextDir The subdirectory where the pom.xml file is located and where the mvn install command must be run webAppWarImage The URL of the images where the JWS Operator pushes the built image webAppWarImagePushSecret The secret that the JWS Operator uses to push images to the repository builder A set of parameters that contain all the information required to build the web application and create and push the image to the image repository Note To ensure that the builder can operate successfully and run commands with different user IDs, the builder must have access to the anyuid security context constraint (SCC). To grant the builder access to the anyuid SCC, enter the following command: oc adm policy add-scc-to-user anyuid -z builder The builder parameter contains the following fields: image The image of the container where the web application is built (for example, quay.io/USDuser/tomcat10-buildah ) imagePullSecret The secret (if specified) that the JWS Operator uses to pull the builder image from the repository applicationBuildScript The script that the builder image uses to build the application .war file and move it to the /mnt directory Note If you do not specify a value for this parameter, the builder image uses a default script that uses Maven and Buildah. Additional resources Operator Capability Levels

Commands:
import-image <my-image> -imagestream:latest --from=quay.io/USDuser/ <my-image> :latest --confirm
apiVersion: web.servers.org/v1alpha1 kind: WebServer metadata: name: <my-image> spec: # Add fields here applicationName: my-app useSessionClustering: true replicas: 2 webImageStream: imageStreamNamespace: <project-name> imageStreamName: <my-image> -imagestream
tag quay.io/USDuser/ <my-image> <my-image> -imagestream:latest --scheduled
--- apiVersion: web.servers.org/v1alpha1 kind: WebServer metadata: name: <my-image> labels: com.company: Red_Hat rht.prod_name: Red_Hat_Runtimes rht.prod_ver: 2023-Q4 rht.comp: JBoss_Web_Server rht.comp_ver: 6.0.0 rht.subcomp: Tomcat 10 rht.subcomp_t: application spec: ----