Our ruleapp requires temp storage to cache application data during rule execution . Since this is only temp storage during rule execution, it is not stored in the external database. The ODM Helm Chart for Kubernetes does not give the option to configure this since it's for a production install.

How can this be accomplished ?

When the ODM Helm chart is installed into a production OpenShift cluster, an external enterprise database is configured for data persistence.

The product Helm chart does not configure internal storage for use within the cluster by default. Therefore, if your application requires usage of internal cluster storage or PVCs, you must extend or patch the cluster after the helm chart is installed in order to mount a persistent volume for your application to use.

This can be accomplished with the following cluster patch cmds:

For example, if your ruleapp requires a PVC to process rules during runtime, you would patch the decisionserverruntime deployment as follows:

$ kubectl patch deployment odm8105-odm-decisionserverruntime -p '{"spec":{"template":{"spec":{"volumes":[{"name":"myAppStorage","persistentVolumeClaim":{"claimName":"myPVC"}}]}}}}'

$ kubectl patch deployment odm8105-odm-decisionserverruntime -p '{"spec": {"template": {"spec": {"containers": [{"name": "odm8105-odm-decisionserverruntime","volumeMounts":[{"name":"myAppStorage","mountPath":"/tmp/tempAppStorage"}]}]}}}}'

The commands above show an example of patching the existing ODM decisionserverruntime deployment to create internal container storage accessible by the decisionserverruntime pod by using a PVC.

It is assumed that the yaml for the PV/PVC is based on StorageClasses that are available within your OpenShift cluster to provision the storage, i.e. NFS, glusterfs, etc.

If the temp storage volume will only be accessed by 1 pod, in this case,

decisionserverruntime , then you can use hostPath PV.

When the deployment is patched with the example cmds shown, ODM decisionserverruntime deployment changes and will cause some downtime during patching, as a new pod is created (scaled up) when you patch the deployment to attach the PVC, and the prev pod is terminated (scaled down).

This scenario is intended to be performed directly after the Helm chart is installed, and before the ruleapp is deployed in order not to cause any downtime of the execution server workloads in production.

If there is a requirement to add additional storage after the ruleapp is deployed and running in production, you would need to run a cmd to perform a rolling restart of a deployment, if zero downtime of the workloads is required.

This can be done using kubectl and modifying the patch deployment spec with dummy annotations:

$ kubectl patch deployment odm8105-odm-decisionserverruntime -p \

"{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\": {"spec": {"containers": [{"name": "odm8105-odm-decisionserverruntime","volumeMounts": [{"name":"myAppStorage","mountPath":"/tmp/tempAppStorage"}] }}}}}}}"

$ kubectl patch deployment odm8105-odm-decisionserverruntime -p \

"{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\": {"spec":{"volumes":[{"name":"myAppStorage","persistentVolumeClaim":{"claimName":"myPVC"}}]}}}}}}"

Then to start the rolling restart of the deployment:

$ kubectl rollout restart deployment odm8105-odm-decisionserverruntime

In the examples shown, both scenarios will create internal persistent storage for the rule application to use as a temp storage cache as it did within WebSphere or Liberty prior to migrating OpenShift.

The only difference in the scenarios provided are the specific patch deployment cmds and the additional rollout restart to perform a rolling restart of the deployment if the production workloads cannot have any downtime.