Chapter 4. Configuring Operator-based broker deployments

1. The Operator runs the Init Container before the broker application container. The Init Container generates a default address settings configuration. The default address settings configuration is shown below.

   <address-settings>
       <!--
       if you define auto-create on certain queues, management has to be auto-create
       -->
       <address-setting match="activemq.management#">
           <dead-letter-address>DLQ</dead-letter-address>
           <expiry-address>ExpiryQueue</expiry-address>
           <redelivery-delay>0</redelivery-delay>
           <!--
           with -1 only the global-max-size is in use for limiting
           -->
           <max-size-bytes>-1</max-size-bytes>
           <message-counter-history-day-limit>10</message-counter-history-day-limit>
           <address-full-policy>PAGE</address-full-policy>
           <auto-create-queues>true</auto-create-queues>
           <auto-create-addresses>true</auto-create-addresses>
           <auto-create-jms-queues>true</auto-create-jms-queues>
           <auto-create-jms-topics>true</auto-create-jms-topics>
       </address-setting>
   
       <!-- default for catch all -->
       <address-setting match="#">
           <dead-letter-address>DLQ</dead-letter-address>
           <expiry-address>ExpiryQueue</expiry-address>
           <redelivery-delay>0</redelivery-delay>
           <!--
           with -1 only the global-max-size is in use for limiting
           -->
           <max-size-bytes>-1</max-size-bytes>
           <message-counter-history-day-limit>10</message-counter-history-day-limit>
           <address-full-policy>PAGE</address-full-policy>
           <auto-create-queues>true</auto-create-queues>
           <auto-create-addresses>true</auto-create-addresses>
           <auto-create-jms-queues>true</auto-create-jms-queues>
           <auto-create-jms-topics>true</auto-create-jms-topics>
       </address-setting>
   <address-settings>

2. If you have also specified an address settings configuration in your Custom Resource (CR) instance, the Init Container processes that configuration and converts it to XML.
3. Based on the value of the applyRule property in the CR, the Init Container merges or replaces the default address settings configuration shown above with the configuration that you have specified in the CR. The result of this merge or replacement is the final address settings configuration that the broker will use.
4. When the Init Container has finished generating the broker configuration (including address settings), the broker application container starts. When starting, the broker container copies its configuration from the installation directory previously used by the Init Container. You can inspect the address settings configuration in the broker.xml configuration file. For a running broker, this file is located in the /home/jboss/amq-broker/etc directory.

Procedure

1. Start configuring a Custom Resource (CR) instance to define addresses and queues for the broker deployment.

   1. Using the OpenShift command-line interface:

      1. Log in to OpenShift as a user that has privileges to deploy CRs in the project for the broker deployment.

         oc login -u <user> -p <password> --server=<host:port>

      2. Open the sample CR file called broker_activemqartemisaddress_cr.yaml that was included in the deploy/crs directory of the Operator installation archive that you downloaded and extracted.

   2. Using the OpenShift Container Platform web console:

      1. Log in to the console as a user that has privileges to deploy CRs in the project for the broker deployment.
      2. Start a new CR instance based on the address CRD. In the left pane, click Administration → Custom Resource Definitions.
      3. Click the ActiveMQArtemisAddresss CRD.
      4. Click the Instances tab.

      5. Click Create ActiveMQArtemisAddress.

         Within the console, a YAML editor opens, enabling you to configure a CR instance.

2. In the spec section of the CR, add lines to define an address, queue, and routing type. For example:

   apiVersion: broker.amq.io/v2alpha2
   kind: ActiveMQArtemisAddress
   metadata:
       name: myAddressDeployment0
       namespace: myProject
   spec:
       ...
       addressName: myAddress0
       queueName: myQueue0
       routingType: anycast
       ...

   The preceding configuration defines an address named myAddress0 with a queue named myQueue0 and an anycast routing type.

   Note

   In the metadata section, you need to include the namespace property and specify a value only if you are using the OpenShift Container Platform web console to create your CR instance. The value that you should specify is the name of the OpenShift project for your broker deployment.

3. Deploy the CR instance.

   1. Using the OpenShift command-line interface:

      1. Save the CR file.

      2. Switch to the project for the broker deployment.

         $ oc project <project_name>

      3. Create the CR instance.

         $ oc create -f <path/to/address_custom_resource_instance>.yaml

   2. Using the OpenShift web console:

      1. When you have finished configuring the CR, click Create.

4. (Optional) To delete an address and queue previously added to your deployment using a CR instance, use the following command:

   $ oc delete -f <path/to/address_custom_resource_instance>.yaml

Procedure

1. Start configuring a CR instance to add a dead letter address and queue to receive undelivered messages for each broker in the deployment.

   1. Using the OpenShift command-line interface:

      1. Log in to OpenShift as a user that has privileges to deploy CRs in the project for the broker deployment.

         oc login -u <user> -p <password> --server=<host:port>

      2. Open the sample CR file called broker_activemqartemisaddress_cr.yaml that was included in the deploy/crs directory of the Operator installation archive that you downloaded and extracted.

   2. Using the OpenShift Container Platform web console:

      1. Log in to the console as a user that has privileges to deploy CRs in the project for the broker deployment.
      2. Start a new CR instance based on the address CRD. In the left pane, click Administration → Custom Resource Definitions.
      3. Click the ActiveMQArtemisAddresss CRD.
      4. Click the Instances tab.

      5. Click Create ActiveMQArtemisAddress.

         Within the console, a YAML editor opens, enabling you to configure a CR instance.

2. In the spec section of the CR, add lines to specify a dead letter address and queue to receive undelivered messages. For example:

   apiVersion: broker.amq.io/v2alpha2
   kind: ActiveMQArtemisAddress
   metadata:
       name: ex-aaoaddress
   spec:
       ...
       addressName: myDeadLetterAddress
       queueName: myDeadLetterQueue
       routingType: anycast
       ...

   The preceding configuration defines a dead letter address named myDeadLetterAddress with a dead letter queue named myDeadLetterQueue and an anycast routing type.

   Note

   In the metadata section, you need to include the namespace property and specify a value only if you are using the OpenShift Container Platform web console to create your CR instance. The value that you should specify is the name of the OpenShift project for your broker deployment.

3. Deploy the address CR instance.

   1. Using the OpenShift command-line interface:

      1. Save the CR file.

      2. Switch to the project for the broker deployment.

         $ oc project <project_name>

      3. Create the address CR.

         $ oc create -f <path/to/address_custom_resource_instance>.yaml

   2. Using the OpenShift web console:

      1. When you have finished configuring the CR, click Create.

4. Start configuring a Custom Resource (CR) instance for a broker deployment.

   1. From a sample CR file:

      1. Open the sample CR file called broker_activemqartemis_cr.yaml that was included in the deploy/crs directory of the Operator installation archive that you downloaded and extracted.

   2. Using the OpenShift Container Platform web console:

      1. Start a new CR instance based on the main broker CRD. In the left pane, click Administration → Custom Resource Definitions.
      2. Click the ActiveMQArtemis CRD.
      3. Click the Instances tab.

      4. Click Create ActiveMQArtemis.

         Within the console, a YAML editor opens, enabling you to configure a CR instance.

   For a basic broker deployment, a configuration might resemble that shown below. This configuration is the default content of the broker_activemqartemis_cr.yaml sample CR file.

   apiVersion: broker.amq.io/v2alpha4
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
     application: ex-aao-app
   spec:
       version: 7.8.5
       deploymentPlan:
           size: 1
           image: placeholder
           requireLogin: false
           persistenceEnabled: true
           journalType: nio
           messageMigration: true

   Observe that in the broker_activemqartemis_cr.yaml sample CR file, the image property is set to a default value of placeholder. This value indicates that, by default, the image property does not specify a broker container image to use for the deployment. To learn how the Operator determines the appropriate broker container image to use, see Section 2.4, “How the Operator chooses container images”.

   Note

   In the metadata section, you need to include the namespace property and specify a value only if you are using the OpenShift Container Platform web console to create your CR instance. The value that you should specify is the name of the OpenShift project for your broker deployment.

5. In the deploymentPlan section of the CR, add a new addressSettings section that contains a single addressSetting section, as shown below.

   spec:
       version: 7.8.5
       deploymentPlan:
           size: 1
           image: placeholder
           requireLogin: false
           persistenceEnabled: true
           journalType: nio
           messageMigration: true
           addressSettings:
               addressSetting:

6. Add a single instance of the match property to the addressSetting block. Specify an address-matching expression. For example:

   spec:
       version: 7.8.5
       deploymentPlan:
           size: 1
           image: placeholder
           requireLogin: false
           persistenceEnabled: true
           journalType: nio
           messageMigration: true
           addressSettings:
               addressSetting:
                -  match: myAddress

   match

   Specifies the address, or set of address to which the broker applies the configuration that follows. In this example, the value of the match property corresponds to a single address called myAddress.

7. Add properties related to undelivered messages and specify values. For example:

   spec:
       version: 7.8.5
       deploymentPlan:
           size: 1
           image: placeholder
           requireLogin: false
           persistenceEnabled: true
           journalType: nio
           messageMigration: true
           addressSettings:
               addressSetting:
                -  match: myAddress
                   deadLetterAddress: myDeadLetterAddress
                   maxDeliveryAttempts: 5

   deadLetterAddress

   Address to which the broker sends undelivered messages.

   maxDeliveryAttempts

   Maximum number of delivery attempts that a broker makes before moving a message to the configured dead letter address.

   In the preceding example, if the broker makes five unsuccessful attempts to deliver a message to an address that begins with myAddress, the broker moves the message to the specified dead letter address, myDeadLetterAddress.

8. (Optional) Apply similar configuration to another address or set of addresses. For example:

   spec:
       version: 7.8.5
       deploymentPlan:
           size: 1
           image: placeholder
           requireLogin: false
           persistenceEnabled: true
           journalType: nio
           messageMigration: true
           addressSettings:
               addressSetting:
                -  match: myAddress
                   deadLetterAddress: myDeadLetterAddress
                   maxDeliveryAttempts: 5
                -  match: 'myOtherAddresses*'
                   deadLetterAddress: myDeadLetterAddress
                   maxDeliveryAttempts: 3

   In this example, the value of the second match property includes an asterisk wildcard character. The wildcard character means that the preceding configuration is applied to any address that begins with the string myOtherAddresses.

   Note

   If you use a wildcard expression as a value for the match property, you must enclose the value in single quotation marks, for example, 'myOtherAddresses*'.

9. At the beginning of the addressSettings section, add the applyRule property and specify a value. For example:

   spec:
       version: 7.8.5
       deploymentPlan:
           size: 1
           image: placeholder
           requireLogin: false
           persistenceEnabled: true
           journalType: nio
           messageMigration: true
           addressSettings:
               applyRule: merge_all
               addressSetting:
                -  match: myAddress
                   deadLetterAddress: myDeadLetterAddress
                   maxDeliveryAttempts: 5
                -  match: 'myOtherAddresses*'
                   deadLetterAddress: myDeadLetterAddress
                   maxDeliveryAttempts: 3

   The applyRule property specifies how the Operator applies the configuration that you add to the CR for each matching address or set of addresses. The values that you can specify are:

   merge_all

   • For address settings specified in both the CR and the default configuration that match the same address or set of addresses:

     • Replace any property values specified in the default configuration with those specified in the CR.
     • Keep any property values that are specified uniquely in the CR or the default configuration. Include each of these in the final, merged configuration.
   • For address settings specified in either the CR or the default configuration that uniquely match a particular address or set of addresses, include these in the final, merged configuration.

   merge_replace

   • For address settings specified in both the CR and the default configuration that match the same address or set of addresses, include the settings specified in the CR in the final, merged configuration. Do not include any properties specified in the default configuration, even if these are not specified in the CR.
   • For address settings specified in either the CR or the default configuration that uniquely match a particular address or set of addresses, include these in the final, merged configuration.

   replace_all

   Replace all address settings specified in the default configuration with those specified in the CR. The final, merged configuration corresponds exactly to that specified in the CR.

   Note

   If you do not explicitly include the applyRule property in your CR, the Operator uses a default value of merge_all.

10. Deploy the broker CR instance.

    1. Using the OpenShift command-line interface:

       1. Save the CR file.

       2. Create the CR instance.

          $ oc create -f <path/to/broker_custom_resource_instance>.yaml

    2. Using the OpenShift web console:

       1. When you have finished configuring the CR, click Create.

Procedure

1. Start configuring a Custom Resource (CR) instance for the broker deployment.

   1. Using the OpenShift command-line interface:

      1. Log in to OpenShift as a user that has privileges to deploy CRs in the project in which you are creating the deployment.

         oc login -u <user> -p <password> --server=<host:port>

      2. Open the sample CR file called broker_activemqartemis_cr.yaml that was included in the deploy/crs directory of the Operator installation archive that you downloaded and extracted.

   2. Using the OpenShift Container Platform web console:

      1. Log in to the console as a user that has privileges to deploy CRs in the project in which you are creating the deployment.
      2. Start a new CR instance based on the main broker CRD. In the left pane, click Administration → Custom Resource Definitions.
      3. Click the ActiveMQArtemis CRD.
      4. Click the Instances tab.

      5. Click Create ActiveMQArtemis.

         Within the console, a YAML editor opens, enabling you to configure a CR instance.

   For a basic broker deployment, a configuration might resemble that shown below. This configuration is the default content of the broker_activemqartemis_cr.yaml sample CR file.

   apiVersion: broker.amq.io/v2alpha4
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
     application: ex-aao-app
   spec:
       version: 7.8.5
       deploymentPlan:
           size: 1
           image: placeholder
           requireLogin: false
           persistenceEnabled: true
           journalType: nio
           messageMigration: true

   Observe that in the broker_activemqartemis_cr.yaml sample CR file, the image property is set to a default value of placeholder. This value indicates that, by default, the image property does not specify a broker container image to use for the deployment. To learn how the Operator determines the appropriate broker container image to use, see Section 2.4, “How the Operator chooses container images”.

   Note

   In the metadata section, you need to include the namespace property and specify a value only if you are using the OpenShift Container Platform web console to create your CR instance. The value that you should specify is the name of the OpenShift project for your broker deployment.

2. To specify broker storage requirements, in the deploymentPlan section of the CR, add a storage section. Add a size property and specify a value. For example:

   spec:
       version: 7.8.5
       deploymentPlan:
           size: 1
           image: placeholder
           requireLogin: false
           persistenceEnabled: true
           journalType: nio
           messageMigration: true
           storage:
               size: 4Gi

   storage.size

   Size, in bytes, of the Persistent Volume Claim (PVC) that each broker Pod requires for persistent storage. This property applies only when persistenceEnabled is set to true. The value that you specify must include a unit. Supports byte notation (for example, K, M, G), or the binary equivalents (Ki, Mi, Gi).

3. Deploy the CR instance.

   1. Using the OpenShift command-line interface:

      1. Save the CR file.

      2. Switch to the project in which you are creating the broker deployment.

         $ oc project <project_name>

      3. Create the CR instance.

         $ oc create -f <path/to/custom_resource_instance>.yaml

   2. Using the OpenShift web console:

      1. When you have finished configuring the CR, click Create.

Procedure

1. Start configuring a Custom Resource (CR) instance for the broker deployment.

   1. Using the OpenShift command-line interface:

      1. Log in to OpenShift as a user that has privileges to deploy CRs in the project in which you are creating the deployment.

         oc login -u <user> -p <password> --server=<host:port>

      2. Open the sample CR file called broker_activemqartemis_cr.yaml that was included in the deploy/crs directory of the Operator installation archive that you downloaded and extracted.

   2. Using the OpenShift Container Platform web console:

      1. Log in to the console as a user that has privileges to deploy CRs in the project in which you are creating the deployment.
      2. Start a new CR instance based on the main broker CRD. In the left pane, click Administration → Custom Resource Definitions.
      3. Click the ActiveMQArtemis CRD.
      4. Click the Instances tab.

      5. Click Create ActiveMQArtemis.

         Within the console, a YAML editor opens, enabling you to configure a CR instance.

   For a basic broker deployment, a configuration might resemble that shown below. This configuration is the default content of the broker_activemqartemis_cr.yaml sample CR file.

   apiVersion: broker.amq.io/v2alpha4
   kind: ActiveMQArtemis
   metadata:
     name: ex-aao
     application: ex-aao-app
   spec:
       version: 7.8.5
       deploymentPlan:
           size: 1
           image: placeholder
           requireLogin: false
           persistenceEnabled: true
           journalType: nio
           messageMigration: true

   Observe that in the broker_activemqartemis_cr.yaml sample CR file, the image property is set to a default value of placeholder. This value indicates that, by default, the image property does not specify a broker container image to use for the deployment. To learn how the Operator determines the appropriate broker container image to use, see Section 2.4, “How the Operator chooses container images”.

   Note

   In the metadata section, you need to include the namespace property and specify a value only if you are using the OpenShift Container Platform web console to create your CR instance. The value that you should specify is the name of the OpenShift project for your broker deployment.

2. In the deploymentPlan section of the CR, add a resources section. Add limits and requests sub-sections. In each sub-section, add a cpu and memory property and specify values. For example:

   spec:
       version: 7.8.5
       deploymentPlan:
           size: 1
           image: placeholder
           requireLogin: false
           persistenceEnabled: true
           journalType: nio
           messageMigration: true
           resources:
               limits:
                   cpu: "500m"
                   memory: "1024M"
               requests:
                   cpu: "250m"
                   memory: "512M"

   limits.cpu

   Each broker container running in a Pod in the deployment cannot exceed this amount of host-node CPU usage.

   limits.memory

   Each broker container running in a Pod in the deployment cannot exceed this amount of host-node memory usage.

   requests.cpu

   Each broker container running in a Pod in the deployment requests this amount of host-node CPU. This value is the minimum amount of CPU required for the broker container to run.

   requests.memory

   Each broker container running in a Pod in the deployment requests this amount of host-node memory. This value is the minimum amount of memory required for the broker container to run.

3. Deploy the CR instance.

   1. Using the OpenShift command-line interface:

      1. Save the CR file.

      2. Switch to the project in which you are creating the broker deployment.

         $ oc project <project_name>

      3. Create the CR instance.

         $ oc create -f <path/to/custom_resource_instance>.yaml

   2. Using the OpenShift web console:

      1. When you have finished configuring the CR, click Create.

Procedure

1. In the deploy/crs directory of the Operator archive that you downloaded and extracted during your initial installation, open the broker_activemqartemis_cr.yaml Custom Resource (CR) file.

2. In the acceptors element, add a named acceptor. Add the protocols and port parameters. Set values to specify the messaging protocols to be used by the acceptor and the port on each broker Pod to expose for those protocols. For example:

   spec:
   ...
     acceptors:
     - name: my-acceptor
       protocols: amqp
       port: 5672
   ...

   The configured acceptor exposes port 5672 to AMQP clients. The full set of values that you can specify for the protocols parameter is shown in the table.

   Protocol	Value
   Core Protocol	core
   AMQP	amqp
   OpenWire	openwire
   MQTT	mqtt
   STOMP	stomp
   All supported protocols	all

   Note

   • For each broker Pod in your deployment, the Operator also creates a default acceptor that uses port 61616. This default acceptor is required for broker clustering and has Core Protocol enabled.
   • By default, the AMQ Broker management console uses port 8161 on the broker Pod. Each broker Pod in your deployment has a dedicated Service that provides access to the console. For more information, see Chapter 5, Connecting to AMQ Management Console for an Operator-based broker deployment.

3. To use another protocol on the same acceptor, modify the protocols parameter. Specify a comma-separated list of protocols. For example:

   spec:
   ...
     acceptors:
     - name: my-acceptor
       protocols: amqp,openwire
       port: 5672
   ...

   The configured acceptor now exposes port 5672 to AMQP and OpenWire clients.

4. To specify the number of concurrent client connections that the acceptor allows, add the connectionsAllowed parameter and set a value. For example:

   spec:
   ...
     acceptors:
     - name: my-acceptor
       protocols: amqp,openwire
       port: 5672
       connectionsAllowed: 5
   ...

5. By default, an acceptor is exposed only to clients in the same OpenShift cluster as the broker deployment. To also expose the acceptor to clients outside OpenShift, add the expose parameter and set the value to true.

   In addition, to enable secure connections to the acceptor from clients outside OpenShift, add the sslEnabled parameter and set the value to true.

   spec:
   ...
     acceptors:
     - name: my-acceptor
       protocols: amqp,openwire
       port: 5672
       connectionsAllowed: 5
       expose: true
       sslEnabled: true
       ...
   ...

   When you enable SSL (that is, Secure Sockets Layer) security on an acceptor (or connector), you can add related configuration, such as:

   • The secret name used to store authentication credentials in your OpenShift cluster. A secret is required when you enable SSL on the acceptor. For more information on generating this secret, see Section 4.6.2, “Securing broker-client connections”.
   • The Transport Layer Security (TLS) protocols to use for secure network communication. TLS is an updated, more secure version of SSL. You specify the TLS protocols in the enabledProtocols parameter.
   • Whether the acceptor uses two-way TLS, also known as mutual authentication, between the broker and the client. You specify this by setting the value of the needClientAuth parameter to true.

Procedure

1. Open the Custom Resource (CR) instance in which you previously defined an AMQP acceptor.

   1. Using the OpenShift command-line interface:

      $ oc edit -f <path/to/custom-resource-instance>.yaml

   2. Using the OpenShift Container Platform web console:

      1. In the left navigation menu, click Administration → Custom Resource Definitions
      2. Click the ActiveMQArtemis CRD.
      3. Click the Instances tab.
      4. Locate the CR instance that corresponds to your project namespace.

   A previously-configured AMQP acceptor might resemble the following:

   spec:
   ...
     acceptors:
     - name: my-acceptor
       protocols: amqp
       port: 5672
       connectionsAllowed: 5
       expose: true
       sslEnabled: true
   ...

2. Specify the minimum size, in bytes, of an AMQP message that the broker handles as a large message. For example:

   spec:
   ...
     acceptors:
     - name: my-acceptor
       protocols: amqp
       port: 5672
       connectionsAllowed: 5
       expose: true
       sslEnabled: true
       amqpMinLargeMessageSize: 204800
       ...
   ...

   In the preceding example, the broker is configured to accept AMQP messages on port 5672. Based on the value of amqpMinLargeMessageSize, if the acceptor receives an AMQP message with a body larger than or equal to 204800 bytes (that is, 200 kilobytes), the broker stores the message as a large message.

   The broker stores the message in the large messages directory (/opt/<custom-resource-name>/data/large-messages, by default) on the persistent volume (PV) used by the broker for message storage.

   If you do not explicitly specify a value for the amqpMinLargeMessageSize property, the broker uses a default value of 102400 (that is, 100 kilobytes).

   If you set amqpMinLargeMessageSize to a value of -1, large message handling for AMQP messages is disabled.

1. When a broker Pod in the deployment shuts down due to failure or intentional scaledown of the deployment, the Operator automatically starts a scaledown controller to prepare for message migration. The scaledown controller runs in the same OpenShift project name as the broker cluster.
2. The scaledown controller registers itself and listens for Kubernetes events that are related to Persistent Volume Claims (PVCs) in the project.

3. To check for Persistent Volumes (PVs) that have been orphaned, the scaledown controller looks at the ordinal on the volume claim. The controller compares the ordinal on the volume claim to that of the broker Pods that are still running in the StatefulSet (that is, the broker cluster) in the project.

   If the ordinal on the volume claim is higher than the ordinal on any of the broker Pods still running in the broker cluster, the scaledown controller determines that the broker Pod at that ordinal has been shut down and that messaging data must be migrated to another broker Pod.

4. The scaledown controller starts a drainer Pod. The drainer Pod runs the broker and executes the message migration. Then, the drainer Pod identifies an alternative broker Pod to which the orphaned messages can be migrated.

   Note

   There must be at least one broker Pod still running in your deployment for message migration to occur.

Procedure

1. In the deploy/crs directory of the Operator repository that you originally downloaded and extracted, open the main broker CR, broker_activemqartemis_cr.yaml.

2. In the main broker CR set messageMigration and persistenceEnabled to true.

   These settings mean that when you later scale down the size of your clustered broker deployment, the Operator automatically starts a scaledown controller and migrates messages to a broker Pod that is still running.

3. In your existing broker deployment, verify which Pods are running.

   $ oc get pods

   You see output that looks like the following.

   activemq-artemis-operator-8566d9bf58-9g25l   1/1   Running   0   3m38s
   ex-aao-ss-0                                  1/1   Running   0   112s
   ex-aao-ss-1                                  1/1   Running   0   8s

   The preceding output shows that there are three Pods running; one for the broker Operator itself, and a separate Pod for each broker in the deployment.

4. Log into each Pod and send some messages to each broker.

   1. Supposing that Pod ex-aao-ss-0 has a cluster IP address of 172.17.0.6, run the following command:

      $ /opt/amq-broker/bin/artemis producer --url tcp://172.17.0.6:61616 --user admin --password admin

   2. Supposing that Pod ex-aao-ss-1 has a cluster IP address of 172.17.0.7, run the following command:

      $ /opt/amq-broker/bin/artemis producer --url tcp://172.17.0.7:61616 --user admin --password admin

      The preceding commands create a queue called TEST on each broker and add 1000 messages to each queue.

5. Scale the cluster down from two brokers to one.

   1. Open the main broker CR, broker_activemqartemis_cr.yaml.
   2. In the CR, set deploymentPlan.size to 1.

   3. At the command line, apply the change:

      $ oc apply -f deploy/crs/broker_activemqartemis_cr.yaml

      You see that the Pod ex-aao-ss-1 starts to shut down. The scaledown controller starts a new drainer Pod of the same name. This drainer Pod also shuts down after it migrates all messages from broker Pod ex-aao-ss-1 to the other broker Pod in the cluster, ex-aao-ss-0.

6. When the drainer Pod is shut down, check the message count on the TEST queue of broker Pod ex-aao-ss-0. You see that the number of messages in the queue is 2000, indicating that the drainer Pod successfully migrated 1000 messages from the broker Pod that shut down.