Merge pull request #97 from ibm-messaging/9.4.0

Updates for 9.4.0

README.md

@@ -1,5 +1,5 @@
 # IBM MQ Sample Helm Chart
-This repository provides a helm chart to deploy an IBM® MQ container built from the [IBM MQ Container GitHub repository](https://github.com/ibm-messaging/mq-container), and has been verified against the [9.3.5 branch](https://github.com/ibm-messaging/mq-container/tree/9.3.5).
+This repository provides a helm chart to deploy an IBM® MQ container built from the [IBM MQ Container GitHub repository](https://github.com/ibm-messaging/mq-container), and has been verified against the [9.4.0 branch](https://github.com/ibm-messaging/mq-container/tree/9.4.0).
 
 ## Pre-reqs
 Prior to using the Helm chart you will need to install two dependencies:

charts/ibm-mq/Chart.yaml

@@ -14,9 +14,9 @@
 apiVersion: v2
 name: ibm-mq
 description: IBM MQ queue manager
-version: 9.0.0
+version: 10.0.0
 type: application
-appVersion: 9.3.5.0
+appVersion: 9.4.0.0
 kubeVersion: ">=1.18.0-0"
 keywords:
   - IBM MQ

charts/ibm-mq/README.md

@@ -4,7 +4,7 @@
 
 ## Introduction
 
-This chart deploys a single IBM® MQ server (Queue Manager) built from the [IBM MQ Container GitHub repository](https://github.com/ibm-messaging/mq-container), and has been verified using the [9.3.5 branch](https://github.com/ibm-messaging/mq-container/tree/9.3.5). IBM MQ is messaging middleware that simplifies and accelerates the integration of diverse applications and business data across multiple platforms.  It uses message queues, topics and subscriptions to facilitate the exchanges of information and offers a single messaging solution for cloud and on-premises environments.
+This chart deploys a single IBM® MQ server (Queue Manager) built from the [IBM MQ Container GitHub repository](https://github.com/ibm-messaging/mq-container), and has been verified using the [9.4.0 branch](https://github.com/ibm-messaging/mq-container/tree/9.4.0). IBM MQ is messaging middleware that simplifies and accelerates the integration of diverse applications and business data across multiple platforms.  It uses message queues, topics and subscriptions to facilitate the exchanges of information and offers a single messaging solution for cloud and on-premises environments.
 
 ## Chart Details
 
@@ -106,7 +106,7 @@ Alternatively, each parameter can be specified by using the `--set key=value[,ke
 | ------------------------------- | --------------------------------------------------------------- | ------------------------------------------ |
 | `license`                       | Set to `accept` to accept the terms of the IBM license          | `"not accepted"`                           |
 | `image.repository`              | Image full name including repository                            | `ibmcom/mq`                                |
-| `image.tag`                     | Image tag                                                       | `9.3.5.0-r1`                               |
+| `image.tag`                     | Image tag                                                       | `9.4.0.0-r1`                               |
 | `image.pullPolicy`              | Setting that controls when the kubelet attempts to pull the specified image.                                               | `IfNotPresent`                             |
 | `image.pullSecret`              | An optional list of references to secrets in the same namespace to use for pulling any of the images used by this QueueManager. If specified, these secrets will be passed to individual puller implementations for them to use. For example, in the case of docker, only DockerConfig type secrets are honoured. For more information, see [here](https://kubernetes.io/docs/concepts/containers/images#specifying-imagepullsecrets-on-a-pod)   | `nil`                                      |
 | `metadata.labels`               | The labels field serves as a pass-through for Pod labels. Users can add any label to this field and have it apply to the Pod.                      | `{}`                                       |
@@ -148,6 +148,7 @@ Alternatively, each parameter can be specified by using the `--set key=value[,ke
 | `security.context.seccompProfile.type` | Seccomp stands for secure computing mode and when enabled restricts the calls that can be made to the kernel. For more information, see https://kubernetes.io/docs/tutorials/security/seccomp/ | `nil`                                  |
 | `security.context.supplementalGroups` | A list of groups applied to the first process run in each container, in addition to the container's primary GID. If unspecified, no groups will be added to any container. | `nil`                                  |
 | `security.initVolumeAsRoot`     | This affects the securityContext used by the container which initializes the PersistentVolume. Set this to true if you are using a storage provider which requires you to be the root user to access newly provisioned volumes. Setting this to true affects which Security Context Constraints (SCC) object you can use, and the Queue Manager may fail to start if you are not authorized to use an SCC which allows the root user. Defaults to false. For more information, see https://docs.openshift.com/container-platform/latest/authentication/managing-security-context-constraints.html. | `false`                  |
+| `security.readOnlyRootFilesystem` | Enable readonly root filesystem.  | `false` |
 | `security.runAsUser` | Controls which user ID the containers are run with.  | `nil`                               |
 | `livenessProbe.initialDelaySeconds` | Number of seconds after the container has started before the probe is initiated. Defaults to 90 seconds for SingleInstance. Defaults to 0 seconds for a Native HA and Multi-instance deployments. | `90` - single instance, `0` - Native HA and Multi-instance |
 | `livenessProbe.periodSeconds`   | How often (in seconds) to perform the probe.                                       | 10                                         |
@@ -175,14 +176,15 @@ Alternatively, each parameter can be specified by using the `--set key=value[,ke
 | `route.nodePort.mqtraffic `     | Controls if a node port is created for the MQ data traffic.      | `false`                                    |
 | `route.openShiftRoute.webconsole`     | Controls if an OpenShift Route is created for the MQ web console.       | `false`                                    |
 | `route.openShiftRoute.mqtraffic `     | Controls if an OpenShift Route is created for the MQ data traffic.      | `false`                                    |
-| `log.format`                    | Which log format to use for this container. Use `json`` for JSON-formatted logs from the container. Use `basic` for text-formatted messages. | `basic`                                 |
+| `log.format`                    | Which log format to use for this container. Use `json` for JSON-formatted logs from the container. Use `basic` for text-formatted messages. | `basic`                                 |
 | `log.debug`                     | Enables additional log output for debug purposes. | `false` |
 | `trace.strmqm`                  | Whether to enable MQ trace on the `strmqm` command | `false` |
 | `trace.crtmqdir`                | Whether to enable MQ trace on the `crtmqdir` command | `false` |
 | `trace.crtmqm`                  | Whether to enable MQ trace on `crtmqm` command | `false` |
 | `metrics.enabled`               | Whether or not to enable an endpoint for Prometheus-compatible metrics.                 | `true`                                     |
 | `affinity.nodeAffinity.matchExpressions` | Force deployments to particular nodes. Corresponds to the Kubernetes specification for [NodeSelectorRequirement](https://v1-18.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#nodeselectorrequirement-v1-core)                  | ``                                     |
 | `tolerations` | Allow pods to be scheduled on nodes with particular taints. Corresponds to the Kubernetes specification for [Torleration](https://v1-18.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#toleration-v1-core)                 | ``                                     |
+| `topologySpreadConstraints` | Control how pods are spread across the Kubernetes cluster. Corresponds to the Kubernetes specification for [Pod Topology Spread Constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)                 | ``                                     |
 
 ## Storage
 

charts/ibm-mq/templates/stateful-set.yaml

@@ -87,6 +87,9 @@ spec:
                 - {{ . }}
                 {{- end }}
               {{- end }}
+      {{- if .Values.topologySpreadConstraints }}
+      topologySpreadConstraints: {{ toYaml .Values.topologySpreadConstraints | nindent 8 }}
+      {{- end }}
       {{- if .Values.tolerations }}
       tolerations:
       {{- range $index, $source := .Values.tolerations }}
@@ -126,6 +129,8 @@ spec:
       volumes:
       {{- else if .Values.queueManager.multiinstance.enable }}
       volumes:
+      {{- else if .Values.security.readOnlyRootFilesystem }}
+      volumes:
       {{- end}}
       {{- if .Values.queueManager.multiinstance.enable }}
       - name: {{ $dataVolumeClaimName }}
@@ -249,6 +254,12 @@ spec:
             - key: mqwebuser.xml
               path: mqwebuser.xml
       {{- end }}
+      {{- if .Values.security.readOnlyRootFilesystem }}
+      - name: run-volume
+        emptyDir: {}
+      - name: tmp-volume
+        emptyDir: {}
+      {{- end }}
       terminationGracePeriodSeconds: {{.Values.queueManager.terminationGracePeriodSeconds}}
       containers:
         - name: qmgr
@@ -299,7 +310,7 @@ spec:
           - name: MQ_NATIVE_HA_INSTANCE_2_REPLICATION_ADDRESS
             value: {{ include "ibm-mq.pod2.service" . }}(9414)
           {{- end }}
-          - name: LOG_FORMAT
+          - name: MQ_LOGGING_CONSOLE_FORMAT
             value: {{ .Values.log.format | default "basic" }}
           - name: MQ_ENABLE_METRICS
             value: "{{ .Values.metrics.enabled | default false }}"
@@ -339,6 +350,8 @@ spec:
           volumeMounts:
           {{- else if .Values.queueManager.multiinstance.enable }}
           volumeMounts:
+          {{- else if .Values.security.readOnlyRootFilesystem }}
+          volumeMounts:
           {{- end}}
           {{- if .Values.queueManager.nativeha.tls }}
           {{- if .Values.queueManager.nativeha.tls.secretName }}
@@ -424,9 +437,15 @@ spec:
             subPath: "mqwebuser.xml"
             readOnly: true
           {{- end }}
+          {{- if .Values.security.readOnlyRootFilesystem }}
+          - mountPath: "/run"
+            name: run-volume
+          - mountPath: "/tmp"
+            name: tmp-volume
+          {{- end }}
           securityContext:
             allowPrivilegeEscalation: false
-            readOnlyRootFilesystem: false
+            readOnlyRootFilesystem: {{ .Values.security.readOnlyRootFilesystem }}
             {{- if .Values.security.runAsUser }}
             runAsUser: {{ .Values.security.runAsUser }}
             {{- end }}
@@ -491,7 +510,7 @@ spec:
             value: "{{ .Values.queueManager.name | default .Release.Name | replace "-" "" }}"
           - name: MQ_NATIVE_HA
             value: "{{ .Values.queueManager.nativeha.enable | default false }}"
-          - name: LOG_FORMAT
+          - name: MQ_LOGGING_CONSOLE_FORMAT
             value: {{ .Values.log.format | default "basic" }}
           - name: DEBUG
             value: "{{ .Values.log.debug | default false }}"

charts/ibm-mq/values.yaml

@@ -19,7 +19,7 @@ image:
   # repository is the container repository to use
   repository: icr.io/ibm-messaging/mq
   # tag is the tag to use for the container repository
-  tag: 9.3.5.0-r1
+  tag: 9.4.0.0-r1
   # pullSecret is the secret to use when pulling the image from a private registry
   pullSecret:
   # pullPolicy is either IfNotPresent or Always (https://kubernetes.io/docs/concepts/containers/images/)
@@ -85,6 +85,7 @@ security:
   # initVolumeAsRoot specifies whether or not storage provider requires root permissions to initialize
   initVolumeAsRoot: false
   runAsUser:
+  readOnlyRootFilesystem: false
 
 # queueManager section specifies settings for the MQ Queue Manager
 queueManager:
@@ -186,6 +187,8 @@ affinity:
   nodeAffinity:
     matchExpressions: []
 
+topologySpreadConstraints: {}  
+
 tolerations: []
 
 web: 

samples/AWSEKS/README.md

@@ -19,6 +19,8 @@ Prior to using the Helm chart you will need to install four dependencies:
 1. This will take a minute or so to deploy, and the status can be checked with the following command: `kubectl get pods | grep secureapp`. Wait until one of the three Pods is showing `1/1` under the ready status (only one will ever show this, the remainding two will be `0/1` showing they are replicas).
 
 ## Testing
+The prerequisite is that the IBM MQ is installed under `/opt/mqm` directory or binaries (Redistributable client) are available in the same path on the host machine on which the testing is carried out. 
+
 Navigate to *../test* directory. No modifications should be required, as the endpoint configuration for your environment will be discovered automatically.
 
 1. To initiate the testing, run the **./sendMessage.sh \<namespace\>** command. It will then connect to MQ and start sending messages immediately.

samples/AWSEKSPartnerSolution/README.md

@@ -20,6 +20,8 @@ Prior to using the Helm chart you will need to install four dependencies:
 1. This will take a minute or so to deploy, and the status can be checked with the following command: `kubectl get pods | grep secureapp`. Wait until one of the three Pods is showing `1/1` under the ready status (only one will ever show this, the remainding two will be `0/1` showing they are replicas).
 
 ## Testing
+The prerequisite is that the IBM MQ is installed under `/opt/mqm` directory or binaries (Redistributable client) are available in the same path on the host machine on which the testing is carried out. 
+
 Navigate to *../test* directory. No modifications should be required, as the endpoint configuration for your environment will be discovered automatically.
 
 1. To initiate the testing, run the **./sendMessage.sh \<namespace\>** command. It will then connect to MQ and start sending messages immediately.

samples/AzureAKS/README.md

@@ -27,6 +27,8 @@ Prior to using the Helm chart you will need to install four dependencies:
 1. This will take a minute or so to deploy, and the status can be checked with the following command: `kubectl get pods | grep secureapp`. Wait until one of the three Pods is showing `1/1` under the ready status (only one will ever show this, the remainding two will be `0/1` showing they are replicas).
 
 ## Testing
+The prerequisite is that the IBM MQ is installed under `/opt/mqm` directory or binaries (Redistributable client) are available in the same path on the host machine on which the testing is carried out. 
+
 Navigate to the *../test* directory. No modifications should be required, as the endpoint configuration for your environment will be discovered automatically.
 
 1. To initiate the testing, run the **./sendMessage.sh \<namespace\>** command. It will then connect to MQ and start sending messages immediately.

samples/AzureAKSFreeTier/README.md

@@ -29,6 +29,8 @@ Prior to using the Helm chart you will need to install four dependencies:
 1. This will take a minute or so to deploy, and the status can be checked with the following command: `kubectl get pods | grep secureapp`. Wait until the Pod is showing `1/1` under the ready status.
 
 ## Testing
+The prerequisite is that the IBM MQ is installed under `/opt/mqm` directory or binaries (Redistributable client) are available in the same path on the host machine on which the testing is carried out. 
+
 Navigate to the *../test* directory. No modifications should be required, as the endpoint configuration for your environment will be discovered automatically.
 
 1. To initiate the testing, run the **./sendMessage.sh \<namespace\>** command. It will then connect to MQ and start sending messages immediately.

samples/AzureAKSMultiInstance/README.md

@@ -28,6 +28,8 @@ Prior to using the Helm chart you will need to install four dependencies:
 1. This will take a minute or so to deploy, and the status can be checked with the following command: `kubectl get pods | grep multiinstance`. Wait until one of the three Pods is showing `1/1` under the ready status (only one will ever show this, the remainding two will be `0/1` showing they are replicas).
 
 ## Testing
+The prerequisite is that the IBM MQ is installed under `/opt/mqm` directory or binaries (Redistributable client) are available in the same path on the host machine on which the testing is carried out. 
+
 Navigate to the *../test* directory. No modifications should be required, as the endpoint configuration for your environment will be discovered automatically.
 
 1. To initiate the testing, run the **./sendMessage.sh \<namespace\>** command. It will then connect to MQ and start sending messages immediately.

samples/IBMKubernetesService/README.md

@@ -20,6 +20,8 @@ Prior to using the Helm chart you will need to install/config four dependencies:
 1. This will take a minute or so to deploy, and the status can be checked with the following command: `kubectl get pods | grep secureapp`. Wait until one of the three Pods is showing `1/1` under the ready status (only one will ever show this, the remainding two will be `0/1` showing they are replicas).
 
 ## Testing
+The prerequisite is that the IBM MQ is installed under `/opt/mqm` directory or binaries (Redistributable client) are available in the same path on the host machine on which the testing is carried out. 
+
 Navigate to *../test* directory. No modifications should be required, as the endpoint configuration for your environment will be discovered automatically.
 
 1. To initiate the testing, run the **./sendMessage.sh \<namespace\>** command. It will then connect to MQ and start sending messages immediately.

samples/Minikube/README.md

@@ -25,6 +25,8 @@ Prior to using the Helm chart you will need to install three dependencies:
 Within minikube there is an unfortunate behavior on certain platforms where it is not immediately possible to communicate from the host machine to a node port. The issue was reported in this [GitHub issue](https://github.com/kubernetes/minikube/issues/7344). Therefore there are two sets of instructions, one for Linux and another for alternative platforms.
 
 ### Testing on Linux
+The prerequisite is that the IBM MQ is installed under `/opt/mqm` directory or binaries (Redistributable client) are available in the same path on the host machine on which the testing is carried out. 
+
 Navigate to *../test* directory. No modifications should be required, as the endpoint configuration for your environment will be discovered automatically.
 
 1. To initiate the testing, run the **./sendMessage.sh \<namespace\>** command. It will then connect to MQ and start sending messages immediately.

samples/OpenShiftIBMPower/README.md

@@ -19,6 +19,8 @@ Prior to using the Helm chart you will need to install three dependencies:
 1. This will take a minute or so to deploy, and the status can be checked with the following command: `kubectl get pods | grep secureapp`. Wait until the Pod is showing `1/1` under the ready status.
 
 ## Testing
+The prerequisite is that the IBM MQ is installed under `/opt/mqm` directory or binaries (Redistributable client) are available in the same path on the host machine on which the testing is carried out. 
+
 Navigate to *../test* directory. No modifications should be required, as the endpoint configuration for your environment will be discovered automatically.
 
 1. To initiate the testing, run the **./sendMessage.sh \<namespace\>** command. It will then connect to MQ and start sending messages immediately.

samples/OpenShiftIBMPower/deploy/ibmpower.yaml

@@ -14,7 +14,7 @@
 license: accept
 image:
   repository: cp.icr.io/cp/ibm-mqadvanced-server
-  tag: 9.3.5.0-r1-ppc64le
+  tag: 9.4.0.0-r1-ppc64le
   pullSecret: ibm-entitlement-key
 queueManager:
   mqscConfigMaps: