Customizing microservice resource usage

Edit online

By using a custom values file, you can control how much CPU and memory your microservices use in an IBM® Concert Workflows® instance.

IBM Concert Workflows® is a containerized microservice application that runs on a Kubernetes platform. In a running instance, some microservice container processes need more CPU or memory resources than others.

You can customize the CPU and memory usage of specific microservices by creating a custom values file, then referencing this file when you install or upgrade IBM Concert Workflows®.

In your custom values file, for each microservice whose resource usage you want to control, you specify requests and limits.
  • A request is the minimum guaranteed amount of a resource that is reserved for a container, for example, 500m (millicores) of CPU.
  • A limit is the maximum amount of a resource that can be consumed by a container, for example, 2000m of CPU.

For almost all microservices, default requests and limits are configured for CPU and memory. To view these default values, see Default requests and limits.

When you use a custom file to override default requests and limits, only the microservices that you specify in your custom file are affected. All other microservices will continue to use their default values.
Note:
  • CPU resource requests and limits are enabled for all microservices by default, but can be disabled.
    • To disable CPU limits and requests for all microservices, set the enableCpuResources attribute to false in your custom values file. For an example, see Example custom values files.
    • When CPU limits and requests are disabled in an instance, CPU resources are assigned dynamically based on available cluster resources.
  • Memory resource requests and limits are enabled for all microservices by default and cannot be disabled.
  • You cannot customize CPU and memory requests and limits for these microservices:
    • pliant_faas_image_builder
    • pliant_python_pipreqs

Specifying requests and limits in the custom values file

On the host where IBM Concert Workflows® runs, create a YAML file. For example, run this command: 
vi my-custom-values.yaml
Note: The YAML attribute structure of your custom file must match the structure of the values.yaml file, which is included in your Concert Workflows installation package. For examples of valid custom files, see Example custom values files.
In your new file, specify the custom requests and limits for each microservice that you want to customize by completing these steps:
  1. Determine the parent attribute section for the microservice in the custom values file.
    • For the mysqldb, object_storage, pliant_kv_store, pliant_stats, postgreSQL, and rabbitmq microservices, the parent section is common.
    • For all other microservices, the parent section is rna.
  2. If required, create the parent section (common or rna) in the custom file.
  3. Optional: Specify custom CPU or memory requests for the microservice.
    • In the parent section, create a <microservice_name>.resources.requests section, then specify the resource requests.
    • To specify a CPU request, use the cpu attribute and specify the request in millicores, for example: cpu: 400m
    • To specify a memory request, use the memory attribute and specify the request in bytes, for example: memory: 300Mi
  4. Optional: Specify custom CPU or memory limits for the microservice.
    • In the parent section, create a <microservice_name>.resources.limits section.

    • Specify CPU or memory limits by using the cpu or memory attributes.

In the following example file, customized CPU and memory requests and limits are specified for the postgresql and pliant_api microservices: 
common:
  postgresql:
    resources:
      requests:
        cpu: 500m
        memory: 1Gi
      limits:
        cpu: 1000m
        memory: 2Gi

rna:
  pliant_api:
    resources:
      requests:
        cpu: 400m
        memory: 3Gi
      limits:
        cpu: 1200m
        memory: 5Gi
To override the default values for the microservices that you specified, you must reference the custom values file when you install a new IBM Concert Workflows® instance or upgrade an existing instance.
  • When you install, you create a configuration parameters file (param.ini) and set the value of the WORKFLOWS_OVERRIDE_VALUES parameter to the path of your custom file. For more information, see Installation and deployment.
  • When you upgrade, you update the existing param.ini file and set the WORKFLOWS_OVERRIDE_VALUES value to the path of your custom file. For more information, see the next section.

Overriding requests and limits in an existing instance

The steps you take to override the default requests and limits depend on where your instance runs.

Overriding in an instance that runs on Red Hat® OpenShift®
  1. On the host where IBM Concert Workflows® runs, navigate to the installation folder by running these commands: 
    export INSTALL_DIR=<install_directory>/ibm-concert
cd $INSTALL_DIR
  2. Edit the params.ini file by running this command: 
    vi $INSTALL_DIR/etc/params.ini
  3. Set the value of the WORKFLOWS_OVERRIDE_VALUES parameter to the location and name of the custom file that you created. For example: 
    WORKFLOWS_OVERRIDE_VALUES=/path/to/my-custom-values.yaml
    Save your changes.
  4. Log in to the cluster by running this command: 
    oc login --token=<auth_token> --server=https://api.<cluster-domain>:6443
    • Replace <auth_token> and <cluster_domain> with your authentication token and the domain name for the cluster.
    • You can retrieve a login command that includes these values in your Red Hat OpenShift web console. Click your email address or ID, click Copy Login Command > Display Token, and copy the command. Paste this command at the CLI prompt to log in.
  5. Set up the required environment variables by running these commands: 
    export IBM_REGISTRY_PASSWORD=<ibm_entitlement_key> 
export CW_NS=<cw-namespace> 
export CLUSTER_DOMAIN=`oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}'` 
export CW_ROUTE=solis-gw-${CW_NS}.${CLUSTER_DOMAIN} oc patch image.config.openshift.io/cluster --type=merge -p '{"spec":{"registrySources":{"insecureRegistries":["'${CW_ROUTE}'"]}}}'
    • Replace <ibm_entitlement_key> with the IBM entitlement key that you used when you installed IBM Concert Workflows®.
    • Replace <cw-namespace> with the name of the IBM Concert Workflows® namespace.
  6. Update configuration for the FaaS image registry to ensure that the cluster trusts the fully qualified domain name (FQDN) of your installation host by running this command: 
    oc patch image.config.openshift.io/cluster --type=merge -p '{"spec":{"registrySources":{"insecureRegistries":["'${CW_ROUTE}'"]}}}'
  7. Retrieve the administrator password for the cluster by running this command: 
    oc get secret -n concert-workflows rna-core-pliant-secrets -o jsonpath='{.data.admin-password}' | base64 -d; echo ""
  8. Upgrade your instance by running this command: 
    $INSTALL_DIR/bin/setup --license_acceptance=y --username=admin --password=<admin_pwd> --registry_password=$IBM_REGISTRY_PASSWORD
    Replace <admin_pwd> with the administrator password that you retrieved in the previous step.
Overriding in an instance that runs on K3s in a Linux VM
  1. On the host where IBM Concert Workflows® runs, navigate to the installation folder by running these commands: 
    export INSTALL_DIR=<install_directory>/ibm-concert
cd $INSTALL_DIR
  2. Edit the params.ini file by running this command: 
    vi $INSTALL_DIR/etc/params.ini
  3. Set the value of the WORKFLOWS_OVERRIDE_VALUES parameter to the location and name of the custom file that you created. For example: 
    WORKFLOWS_OVERRIDE_VALUES=/path/to/my-custom-values.yaml
    Save your changes.
  4. Set up the required environment variables by running these commands: 
    export DOCKER_EXE=<podman_docker> 
export IBM_REGISTRY=cp.icr.io/cp
export IBM_REGISTRY_USER=cp
export IBM_REGISTRY_PASSWORD=<ibm_entitlement_key>
    • Replace <podman_or_docker> with the container runtime that you are using (podman or docker).
    • Replace <ibm_entitlement_key> with the IBM entitlement key that you used when you installed IBM Concert Workflows®.
  5. Authenticate with the source image registry by running this command: 
    ${DOCKER_EXE} login ${IBM_REGISTRY} --username=${IBM_REGISTRY_USER} --password=${IBM_REGISTRY_PASSWORD}
  6. Upgrade your instance by running this command: 
    $INSTALL_DIR/bin/setup --license_acceptance=y --username=admin --password=<admin_password> --registry_password=${IBM_REGISTRY_PASSWORD}
    Replace <admin_password> with the password of the administrator user.

Default requests and limits

For IBM Concert Workflows® microservices whose CPU and memory usage can be customized, the default requests and limits are shown in this table:
Table 1. Default microservice resource requests and limits
Microservice name Parent section in values file Default CPU request (millicores) Default CPU limit Default memory request (bytes) Default memory limit
mysqldb common 300m 4000m 750Mi 1.5Gi
postgresql common 300m 600m 750Mi 2Gi
object_storage common 200m 400m 128Mi 1Gi
pliant_kv_store common 100m 500m 256Mi 512Mi
pliant_stats common 100m 500m 128Mi 512Mi
rabbitmq common 300m 600m 128Mi 1024Mi
pliant_api rna 250m 4000m 750Mi 4Gi
solis_gw rna 100m 500m 256Mi 256Mi
pliant_app_gateway rna 100m 350m 128Mi 256Mi
pliant_proxy rna 150m 300m 128Mi 128Mi
pliant_ai rna 300m 750m 256Mi 1024Mi
pliant_front rna 100m 1000m 128Mi 256Mi
pliant_db_migration rna 100m 300m 256Mi 512Mi
pliant_worker_nodejs rna 450m 4000m 256Mi 2048Mi
pliant_worker_nodejs_config rna 500m 4000m 1024Mi 2048Mi
pliant_integrations rna 300m 1000m 1024Mi 2048Mi
pliant_scheduler rna 100m 200m 256Mi 512Mi
pliant_compiler rna 300m 600m 128Mi 768Mi
pliant_metering rna 100m 300m 128Mi 256Mi
pliant_versioning rna 100m 200m 128Mi 256Mi
pliant_flow_converter rna 100m 500m 128Mi 384Mi
pliant_image_registry rna 250m 1000m 500Mi 1Gi
addon_ansible rna 200m 2000m 128Mi 1Gi
addon_expect rna 100m 300m 128Mi 256Mi
addon_faas rna 150m 300m 128Mi 1Gi
addon_mqws rna 100m 300m 128Mi 512Mi
addon_napalm rna 100m 300m 128Mi 256Mi
addon_textfsm rna 100m 300m 128Mi 256Mi
addon_pdf rna 150m 500m 128Mi 256Mi
addon_themes rna 300m 1000m 128Mi 1Gi
addon_toolbox rna 150m 500m 128Mi 1024Mi

Example custom values files

This example file contains customized CPU requests and limits for all microservices: 
common:
  mysqldb:
    resources:
      requests:
        cpu: 500m
      limits:
        cpu: 2000m
  object_storage:
    resources:
      requests:
        cpu: 250m
      limits:
        cpu: 500m
  pliant_kv_store:
    resources:
      requests:
        cpu: 200m
      limits:
        cpu: 400m
  pliant_stats:
    resources:
      requests:
        cpu: 200m
      limits:
        cpu: 500m
  postgresql:
    resources:
      requests:
        cpu: 500m
      limits:
        cpu: 1000m
  rabbitmq:
    resources:
      requests:
        cpu: 300m
      limits:
        cpu: 600m

rna:
  addon_ansible:
    resources:
      requests:
        cpu: 200m
      limits:
        cpu: 500m
  addon_expect:
    resources:
      requests:
        cpu: 150m
      limits:
        cpu: 300m
  addon_faas:
    resources:
      requests:
        cpu: 250m
      limits:
        cpu: 500m
  addon_mqws:
    resources:
      requests:
        cpu: 250m
      limits:
        cpu: 500m
  addon_napalm:
    resources:
      requests:
        cpu: 200m
      limits:
        cpu: 500m
  addon_textfsm:
    resources:
      requests:
        cpu: 150m
      limits:
        cpu: 300m
  addon_pdf:
    resources:
      requests:
        cpu: 250m
      limits:
        cpu: 500m
  addon_themes:
    resources:
      requests:
        cpu: 150m
      limits:
        cpu: 300m
  addon_toolbox:
    resources:
      requests:
        cpu: 150m
      limits:
        cpu: 400m
  pliant_ai:
    resources:
      requests:
        cpu: 300m
      limits:
        cpu: 750m
  pliant_api:
    resources:
      requests:
        cpu: 500m
      limits:
        cpu: 1000m
  pliant_app_gateway:
    resources:
      requests:
        cpu: 200m
      limits:
        cpu: 500m
  pliant_compiler:
    resources:
      requests:
        cpu: 250m
      limits:
        cpu: 500m
  pliant_db_migration:
    resources:
      requests:
        cpu: 250m
      limits:
        cpu: 500m
  pliant_flow_converter:
    resources:
      requests:
        cpu: 250m
      limits:
        cpu: 500m
  pliant_front:
    resources:
      requests:
        cpu: 200m
      limits:
        cpu: 500m
  pliant_image_registry:
    resources:
      requests:
        cpu: 250m
      limits:
        cpu: 500m
  pliant_proxy:
    resources:
      requests:
        cpu: 200m
      limits:
        cpu: 500m
  pliant_scheduler:
    resources:
      requests:
        cpu: 250m
      limits:
        cpu: 500m
  pliant_versioning:
    resources:
      requests:
        cpu: 200m
      limits:
        cpu: 300m
  pliant_worker_nodejs_config:
    resources:
      requests:
        cpu: 300m
      limits:
        cpu: 750m
  pliant_worker_nodejs:
    resources:
      requests:
        cpu: 300m
      limits:
        cpu: 1000m
  pliant_integrations:
    resources:
      requests:
        cpu: 150m
      limits:
        cpu: 200m
  pliant_metering:
    resources:
      requests:
        cpu: 150m
      limits:
        cpu: 300m
  solis_gw:
    resources:
      requests:
        cpu: 250m
      limits:
        cpu: 500m
In this example, CPU requests and limits are disabled for all microservices, and memory requests and limits are specified for the pliant_image_registry and pliant_proxy microservices: 
enableCpuResources: false
rna:
  pliant_image_registry:
    resources:
      requests:
        memory: 500Mi
      limits:
        memory: 2Gi
  pliant_proxy:
    resources:
      requests:
        memory: 128Mi
      limits:
        memory: 1Gi
This example contains customized CPU requests and limits for the pliant_api, pliant_worker_nodejs, postgresql, and mysqldb microservices. This example also includes settings to enable the AI workflow assistant feature, which is disabled by default: 
rna:
  instance:
    ai:
      watsonx_version: "2024-03-14" 
      watsonx_model: "meta-llama/llama-3-3-70b-instruct" 
      watsonx_auth_type: "iam" 
      watsonx_api_key: "AIzaSyDaGmWKa4JsXZ-HjGw7ISLn_3namBGewQe" 
      watsonx_project_id: "230f6381-7dac-45d2-9fa7-b71af09cd3a3" 
      watsonx_cluster_url: "https://us-south.ml.cloud.ibm.com"
  pliant_api:
    resources:
      requests:
        cpu: 500m
      limits:
        cpu: 1000m
  pliant_worker_nodejs:
    resources:
      requests:
        cpu: 300m
      limits:
        cpu: 1000m
common:
  postgresql:
    resources:
      requests:
        cpu: 500m
      limits:
        cpu: 1000m
  mysqldb:
    resources:
      requests:
        cpu: 500m
      limits:
        cpu: 2000m