Release Notes for Red Hat AMQ Broker 7.12

ENTMQBR-9187 - The Operator shows forbidden errors when you deploy a CR and message migration does not work as expected.

If you install the Operator using the Openshift CLI or using Operator Hub with custom YAML files, you can configure the Operator to watch multiple namespaces or a single namespace that is different to the one in which the Operator is installed. In both of these configurations, the following error is displayed when you deploy the ActiveMQArtemis CR:

W0614 14:18:59.355936 1 reflector.go:535] k8s.io/client-go/informers/factory.go:150: failed to list *v1.StatefulSet: statefulsets.apps is forbidden: User "system:serviceaccount:amq-broker-operator-olm:amq-broker-controller-manager" cannot list resource "statefulsets" in API group "apps" at the cluster scope

The broker deployment is created and works as normal. However, if you scale down the deployment subsequently, messages on the broker that was removed are not migrated to another broker and are lost.

To avoid this issue, allow the Operator to watch all namespaces, which is the default, or configure the Operator to watch the single namespace in which the Operator is installed.

ENTMQBR-9103 - NullPointerException when closing multiple threads consuming AMQP

When running a multi-threaded consumer for AMQP messages, the broker sometimes generates WARN-level log messages similar to the following:

2024-05-13 18:11:46,048 WARN [io.netty.util.concurrent.AbstractEventExecutor] A task raised an exception. Task: org.apache.activemq.artemis.protocol.amqp.proton.AMQPLargeMessageWriter$$Lambda$643/0x00007fa4ff5153c0@33bff98e java.lang.NullPointerException: null

The messages are produced when the client finishes consuming messages and are sometimes accompanied by a stack trace.

No messages are lost and the message can be ignored.

ENTMQBR-8106 - AMQ Broker Drainer pod doesn’t function properly after changing MessageMigration in CR

You cannot change the value of the messageMigration attribute in a running broker deployment. To work around this issue, you must set the required value for the messageMigration attribute in a new ActiveMQ Artemis CR and create a new broker deployment.

ENTMQBR-8166 - Self-signed certificate with UseClientAuth=true prevents communication of Operator with Jolokia

If the useClientAuth attribute is set to true in the console section of the ActiveMQ Artemis CR, the Operator is unable to configure certain features, for example, create addresses, on the broker. In the Operator log, you see an error message that ends with remote error: tls: bad certificate.

ENTMQBR-7359 - Change to current handling of credential secret with 7.10.0 Operator

The Operator stores the administrator username and password for connecting to the broker in a secret. The default secret name is in the form <custom-resource-name>-credentials-secret. You can create a secret manually or allow the Operator to create a secret.

If the adminUser and adminPassword attributes are configured in a Custom Resource prior to 7.10.0, the Operator updates a manually-created secret with the values of these attributes. Starting in 7.10.0, the Operator no longer updates a secret that was created manually. Therefore, if you change the values of the adminUser and adminPassword attributes in the CR, you must either:

ENTMQBR-7111 - 7.10 versions of operator tend to remove StatefulSet during upgrade

If you are upgrading to or from AMQ Broker Operator 7.10.0, the new Operator automatically deletes the existing StatefulSet for each deployment during the reconciliation process. When the Operator deletes the StatefulSet, the existing broker pods are deleted, which causes a temporary broker outage.

You can work around this issue by running the following command to manually delete the StatefulSet and orphan the running pods before the Operator gets to delete the StatefulSet: oc delete statefulset <statefulset-name> --cascade=orphan

Manually deleting the StatefulSet during the upgrade process allows the new Operator to reconcile the StatefulSet without deleting the running pods. For more information, see Upgrading the Operator using OperatorHub in Deploying AMQ Broker on OpenShift.

ENTMQBR-5749 - Remove unsupported operators that are visible in OperatorHub

Only the Operators and Operator channels mentioned in Deploying the Operator from OperatorHub are supported. For technical reasons associated with Operator publication, other Operator and channels are visible in the OperatorHub and should be ignored. For reference, the following list shows which Operators are visible, but not supported:

ENTMQBR-4140 - AMQ Broker Operator: Installation becomes unusable if storage.size is improperly specified

If you configure the storage.size property of a Custom Resource (CR) instance to specify the size of the Persistent Volume Claim (PVC) required by brokers in a deployment for persistent storage, the Operator installation becomes unusable if you do not specify this value properly. For example, suppose that you set the value of storage.size to 1 (that is, without specifying a unit). In this case, the Operator cannot use the CR to create a broker deployment. In addition, even if you remove the CR and deploy a new version with storage.size specified correctly, the Operator still cannot use this CR to create a deployment as expected.

To work around this issue, first stop the Operator. In the OpenShift Container Platform web console, click Deployments. For the Pod that corresponds to the AMQ Broker Operator, click the More options menu (three vertical dots). Click Edit Pod Count and set the value to 0. When the Operator Pod has stopped, create a new version of the CR with storage.size correctly specified. Then, to restart the Operator, click Edit Pod Count again and set the value back to 1.

ENTMQBR-4141 - AMQ Broker Operator: Increasing Persistent Volume size requires manual involvement even after recreating Stateful Set

If you try to increase the size of the Persistent Volume Claim (PVC) required by brokers in a deployment for persistent storage, the change does not take effect without further manual steps. For example, suppose that you configure the storage.size property of a Custom Resource (CR) instance to specify an initial size for the PVC. If you modify the CR to specify a different value of storage.size, the existing brokers continue to use the original PVC size. This is the case even if you scale the deployment down to zero brokers and then back up to the original number. However, if you scale the size of the deployment up to add additional brokers, the new brokers use the new PVC size.

To work around this issue, and ensure that all brokers in the deployment use the same PVC size, use the OpenShift Container Platform web console to expand the PVC size used by the deployment. In the console, click Storage → Persistent Volume Claims. Click your deployment. On the Actions drop-down menu in the top-right corner, select Expand PVC and enter a new value.