Configuring custom resources

Before you begin

• Refer to Versioning reference for available version options.
• You must create secrets to the external services that IBM RPA uses. For more information, see Creating IBM RPA secrets.

Basic setup

The following example shows a minimal IBM RPA custom resource that contains all the required sections and properties:

apiVersion: rpa.automation.ibm.com/v1beta1
kind: RoboticProcessAutomation
metadata:
  name: rpa-sample
spec:
  license:
    accept: true
  version: 2.3.0
  tls: {}
  api:
    externalConnection:
      secretName: rpa-db
    firstTenant:
      name: ibm
      owner:
        ownersecret:
          secretName: rpa-owner
    replicas: 1
    smtp:
      port: 587
      server: smtp.example.com
      userSecret:
        secretName: rpa-smtp
    storage: {}
  ui:
    replicas: 1
  ocr:
    replicas: 1  

apiVersion: rpa.automation.ibm.com/v1beta1
kind: RoboticProcessAutomation
metadata:
  name: rpa-sample
spec:
  license:
    accept: true
  version: 2.3.0
  tls: {}
  api:
    externalConnection:
      secretName: rpa-db
    firstTenant:
      name: ibm
      owner:
        ownersecret:
          secretName: rpa-owner
    replicas: 1
    smtp:
      port: 587
      server: smtp.example.com
      userSecret:
        secretName: rpa-smtp
    storage: {}
    webDriverUpdates:
      enabled: true
    systemQueueProvider:
      storage:
        class: my-storage-class
  ui:
    replicas: 1
  ocr:
    replicas: 1  

Template

You can also create a template for your container by using the following fields:

• template (optional)
  The object that describes the pod overrides that are used when pods are created.
  • pod (optional)
    Contains the pod information.
    • metadata (optional)
      Customize the task manager pods metadata.
      • annotations
        Set or override annotations on the task manager pods.
    • spec (optional)
      Contains the pod container and scheduling information.
      • containers (optional)
        Contains the specification for pod container overrides.
        • name (required): For example, taskmanager.
        • resources
          Describes the compute resource requirements.
        • image
          Override the container image.
        • imagePullPolicy
          Override imagePullPolicy.
      • affinity (optional)
        Affinity information for pod scheduling. For more information, see the Kubernetes documentation 🡥.
        • nodeAffinity (optional)
          Use it to select which nodes are selected by the scheduler.
        • podAffinity (optional)
          Use it to influence where your pods are deployed based on already deployed pods.
        • podAntiAffinity (optional)
          Describes the pod anti-affinity scheduling rules, such as to avoid putting this pod in the same node or zone as some other pod.
      • tolerations
        An optional core/v1/Tolerations array to specify toleration for scheduling taints. For more information, see the Kubernetes documentation 🡥.

An example of a template includes:

spec:
  template:
    pod:
      spec:
        containers:
        - name: svc
          resources:
            requests:
              cpu: 8
              memory: 64Gi
            limits:
              cpu: 10
              memory: 128Gi
        - name: sidecar
          resources:
            requests:
              cpu: 1
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
              - matchExpressions:
                - key: kubernetes.io/arch
                  operator: In
                  values:
                  - amd64
          podAntiAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
            - podAffinityTerm:
                labelSelector:
                  matchLabels:
                    app.kubernetes.io/component: rpa
                    app.kubernetes.io/instance: test-instance
                    app.kubernetes.io/managed-by: ibm-rpa-operator
                    app.kubernetes.io/name: apiserver
                    rpa.automation.ibm.com/cr-name: test-instance
                topologyKey: kubernetes.io/hostname
              weight: 80

Labels and annotations

Labels and annotations that are defined on a custom resource can be merged with the labels and annotations that are defined by the operator. Based on priority, the order of these labels and annotations is:

• Template form labels and annotation (highest priority)
• Short form label and annotation
• Default from operator (lowest priority)

The labels and annotations can be applied to pods.

If the CR has only one main deployment, or if the deployments do not need to be configured independently, then you can configure the labels and annotations by using the labels and annotations keys:

spec:
  labels:
    my.custom/label: "foo"
  annotations:
    my.custom/annotation: "bar"

If the CR has multiple components that need to be configured independently, the keys can be included in component subsections:

spec:
  ui:
    labels:
      my.custom/label: "foo"
    annotations:
      my.custom/annotation: "bar"
  api:
    labels:
      my.custom/label: "fizz"
    annotations:
      my.custom/annotation: "buzz"

Or alternatively, the block can be split by component:

spec:
  labels:
    ui:
      my.custom/label: "foo"
    api:
      my.custom/label: "fizz"
  annotations:
    ui:
      my.custom/annotation: "bar"
    api:
      my.custom/annotation: "buzz"

Workload placement with node selectors

The schema must mark nodeSelector fields with the selector spec descriptor.

If there is only one main deployment for the CR, or the deployments do not need to be configured independently, then the node selectors are configured using the nodeSelector key:

spec:
  nodeSelector:
    disktype: ssd

If there are multiple components that need to be configured independently, the key can be included in component subsections:

spec:
  ui:
    nodeSelector:
      type: edge
  api:
    nodeSelector:
      disktype: ssd

Or alternatively, the block can be split by component:

spec:
  nodeSelector:
    ui:
      type: edge
    api:
      disktype: ssd

Customization for Redis

This is an optional Redis resource override that applies a uniform memory and CPU limit change to all the Redis resources, namely ProxyLog, DB, Proxy, and Mgmt.

The CR override is a top-level CR attribute sharedCache, as follows:

sharedCache:
  memoryLimit: 250Mi
  cpuLimit: 0.8

By default, the value of memoryLimit is 100Mi and cpuLimit is set to 0.4.

Compute resource limits

You can customize compute resource limits, in terms of CPU and memory. It uses the field name resources.

This is specified as follows:

Here's an example:

resources:
  requests:
    cpu: "8"
    memory: 64Gi
  limits:
    cpu: "12"
    memory: 128Gi

This may also be used in the template form as an override to be merged onto a container. This should only be used where a container is unlikely to have its resource limits changed by a user:

spec:
  template:
    pod:
      containers:
      - name: helper-pod
        resources:
          requests:
            cpu: 0.5
            memory: 128Mi
          limits:
            cpu: 1
            memory: 128Mi

What to do next

You can proceed to deploy your instance. For more information, see Deploy the IBM RPA custom resource.

Related links

Parent topic:

• Deploying and configuring IBM Robotic Process Automation on Red Hat® OpenShift® Container Platform