MQ

Usually, when we have an IBM MQ Queue manager deployed on a Red Hat OpenShift Container Platform cluster, and when we have made some changes to the ConfigMap, a manual restart of the queue manager pod is required (by deleting it or  by editing the queue manager YAML, for example by changing or adding an annotation or label) to pick up the latest changes.

There is another way to trigger a rolling update of the queue manager which could be achieved without editing the YAML file of the queue manager. This is applicable to both Single Instance and Native HA queue manager configurations. This could be done via "Kustomize",  a Kubernetes configuration transformation tool, as shown in the following steps: 

1. Create a new directory:

 mkdir [KUSTOMIZE_DIRECTORY]
 
 Note: The name and location of this directory does not matter.

2.  In the above created directory create the following files:

     a) kustomization-config-mq.yaml

nameReference:
  - kind: ConfigMap
    fieldSpecs:
      - path: spec/queueManager/mqsc/configMap/name
        kind: QueueManager
  - kind: ConfigMap
    fieldSpecs:
      - path: spec/queueManager/ini/configMap/name
        kind: QueueManager
  - kind: Secret
    fieldSpecs:
      - path: spec/queueManager/ini/secret/name
        kind: QueueManager
  - kind: Secret
    fieldSpecs:
      - path: spec/queueManager/mqsc/secret/name
        kind: QueueManager
  - kind: Secret
    fieldSpecs:
      - path: spec/pki/keys/secret/secretName
        kind: QueueManager
  - kind: Secret
    fieldSpecs:
      - path: spec/pki/keys/secret/secretName
        kind: QueueManager
  - kind: Secret
    fieldSpecs:
      - path: spec/pki/trust/secret/secretName
        kind: QueueManager
  - kind: Secret
    fieldSpecs:
      - path: spec/queueManager/availability/tls/secretName
        kind: QueueManager
  - kind: Secret
    fieldSpecs:
      - path: spec/imagePullSecrets
        kind: QueueManager

   b)  kustomization.yaml

          Configure a “kustomization” which can be processed by the “kustomize” code integrated into the “oc” and “kubectl” commands.

           Important: You must edit the below YAML to add the namespace that you have  deployed your IBM MQ Operator into. 
           

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

configurations:
  - kustomization-config-mq.yaml

# Set the namespace for all resources
namespace: [NAMESPACE_OF_OPERATOR]

# Generate the ConfigMap resources from the raw MQSC file
configMapGenerator:
  - name: myqm-config
    files:
      - myqm.mqsc
      - myqm.ini

# Include these resources
resources:
  - myqm.yaml

  c)  myqm.mqsc   (sample. Please refer to: MQSC commands reference)

DEFINE QLOCAL('APPQ') REPLACE

  d)  myqm.ini (sample. Please refer to: Queue manager configuration files, qm.ini)

Log:
   LogPrimaryFiles=50
   LogSecondaryFiles=40

  e) myqm.yaml

      Note: This is an example YAML file for a Native HA Queue Manager, with the resources to be included for Kustomization.
   

apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: myqm-native
spec:
  license:
    accept: true
    license: <keyword id="ctrcurrentlicense"/>
    use: NonProduction
  queueManager:
    availability:
      type: NativeHA
    mqsc:
      - configMap:
          name: myqm-config
          items:
            - myqm.mqsc
    ini:
      - configMap:
            name: myqm-config
            items:
              - myqm.ini
  version: <keyword id="ctrcurrent"/>
  web:
    enabled: false

3.  Navigate to the directory that you have created, for example using:
     
     cd [KUSTOMIZE_DIRECTORY]

4.  Set your active project to the namespace specified in kustomization.yaml from step 2.b, for example using:

      oc project [NAMESPACE_OF_OPERATOR]

5.  Run the following command:

    oc apply -k .

     Important: The command in step 5 must be run whenever changes to MQSC and/or  INI files are made.
     You will then see an output like the one below:

configmap/myqm-config-46kdc9c6cg created
queuemanager.mq.ibm.com/myqm-native created

In these example steps myqm-config includes myqm.mqsc and myqm.ini. When either, or both, of these files are updated, the -k option (i.e. Kustomize) in the command in step 5 will generate a new ConfigMap due to detecting a change to myqm-config. The Queue Manager YAML will then be updated with the new ConfigMap name. This change to the Queue Manager will be recognised by the IBM MQ Operator, which will automatically trigger a pod restart. For Native HA deployments, the stand-by pods are restarted first, followed by a restart of the active pod. This ensures the pods pick up the changes with minimal downtime.
Please refer to our example page on Supplying MQSC and INI files for examples of what you should expect your ConfigMap and Queue Manager YAML to look like after deployment.

PS: Kustomize can generate a new ConfigMap if there are any changes.  This also has an advantage that your old ConfigMap still exists, so you have a history of changes. In case you’re sure that the old ConfigMaps are no longer needed, you will need to manually clear them up.

Triggering a rolling update when MQSC/INI is included in the image

There could be a case where you have created an IBM MQ container image with custom MQSC/INI files using a OpenShift Container Platform BuildConfig or pipeline. Please refer to Building an image with custom MQSC and INI files, using the Red Hat OpenShift CLI for more details. In that case, the following could be helpful in picking up any changes in MQSC/INI files for a running MQ Queue Manager instance.

Each time we make a change to the MQSC scripts or the INI file contents in the spec.source.dockerfile section of the build config, we have to apply the build config with the latest changes and start a new build. The image stream will generate a new image identifier each time a new image build is triggered. The older builds stay as is and could be deleted if no longer required.

For example:

1. Either update the QueueManager YAML spec.queueManager.image field with a new image tag ( latest generated one by the image stream ), for example: image-registry.openshift-image-registry.svc:5000/<your_namespace>/mymq@<latest_image_identifier>

Or,

2. Update the spec.output.to.name to a new image name, ex: mymq:<new_custom_image_stream_tag_name>. This should be done before starting the new build with the latest changes. After the new build is successfully running, you can see a new ImageStreamTag in ImageStreams , with a new image identifier , of course. Then update the spec.queueManager.image with the new image name (you could also use the corresponding identifier as in step 1) .
   like - image-registry.openshift-image-registry.svc:5000/<your_namespace>/mymq:<new_custom_image_stream_tag_name>

Following either of the above steps will cause the QM pod to restart and will pick up the new MQSC script and(or) the INI file changes as defined in the spec.source.dockerfile section of the build config.

3. Another way could be to add  imagePullPolicy: Always  to spec.template.pod.containers to the existing QueueManager YAML. By default , the value of imagePullPolicy is IfNotPresent . With this , we don't need to update the image stream tag name being referenced in the Queue manager YAML (see step 1). All that is needed is a restart of each queue manager pod (deleting it would automatically trigger a restart). In the case of a NativeHA queue manager, stand-by pods should be restarted prior to restarting the active pod. After the restart, we can see that the MQSC/INI file changes have been picked up.