the operator is not able to deploy application images provisioned with wildfly-maven-plugin

[jmesnil]

Application images created by the wildfly-maven-plugin's package goal use managed deployments.

The deployment bits are stored in the server data directory (in the content subdir) and the digest of the deployment is referenced in the standalone.xml configuration.

One of the key feature of the WildFly Operator is to use persistent storage (that survives pod restarts) to be able to recover any transaction during scale down. The operator mounts the server data directory in a persistent volume to achieve this.

However, this makes it impossible to deploy application images created by the wildfly-maven-plugin as the volume mounted at the data mount path will override the directory inside the container image that contains the deployment bits.

This results in an error:

10:55:24,076 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "wuar-demo.war")]) - failure description: "WFLYSRV0137: No deployment content with hash e0ff941433302a0b283d8a02b7ae841a3c6c6f40 is available in the deployment content repository for deployment 'wuar-demo.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
10:55:24,097 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. - Server configuration file in use: standalone.xml

[jmesnil]

I was able to deploy an application images created by the wildfly-maven-plugin with the following changes:

• remove the volume mounted for data
• add several volumes mounted for the data subdirs that are required for tx recovery (kernel, tx-ojbect-store, ejb-xa-recovery)
• change JBOSS_HOME to /opt/wildfly

[jmesnil]

#244 contains the changes to be able to deploy application image built with the wildfly-maven-plugin.

However they break the existing integration tests that relies on previous WildFly S2I images (before WildFly 26). I've not been able to find a way to have the operator deploy both types of application image (from before WildFly 26 with the legacy S2I images and with the new runtime image with the wildfly-maven-plugin-.

[jmesnil]

#244 is not enough to fix the issue reliably. We have many subsystems and extensions that writes to the data directory (eg for audit logging, messaging). The operator can not mount all eventual subdirectories that would need to survive pod restarts.

A long term fix would likely be inside WildFly to have extensions that writes "server data" reliably categorise the scope and intent of the data:

• must the data be present for the server to boot (eg the deployment content)
• must the data survive server restart (and pod restart) (eg the tx recovery log)

[jmesnil]

This issue was resolved in https://issues.redhat.com/browse/WFMP-185 and the operator is able to deploy application provisioned with the wildfly-maven-plugin as long as the version is 4.1.0.Beta2 or above