Configuring Automation Decision Services

Before you install, configure the custom resource YAML file for your Automation Decision Services deployment.

Before you begin

Make sure you follow the instructions in Preparing to install Automation Decision Services where you configure important settings such as secrets, certificates, persistent volumes, as well as Machine Learning providers.

Procedure

  1. Specify which components to deploy and how to access them from outside the cluster.

    To do so, set the following parameters in the custom resource YAML file.

    Table 1. Basic Automation Decision Services configuration parameters
    Parameter Description Default
    ads_configuration.decision_designer.enabled A flag to control whether Decision Designer is deployed or not. false
    For 21.0.1 ads_configuration.decision_designer.embedded_build_and_run.enabled A flag to control whether the embedded build and run services are deployed as part of Decision Designer or not. Only applicable if ads_configuration.decision_designer.enabled is true. true
    ads_configuration.decision_runtime.enabled A flag to control whether the decision runtime is deployed or not. false
    For 21.0.1 ads_configuration.decision_runtime_service.archive_repository.url_prefix In decision runtime execution calls, indicates the prefix of the URL that resolves the decision archive location based on the decisionId. For more information, see Calling decision services. Corresponds to the samples decision archives.

    https://github.com/icp4a/automation-decision-services-samples/raw/21.0.2/archives/

    For 21.0.1 https://github.com/icp4a/automation-decision-services-samples/raw/21.0.1/archives/

    ads_configuration.external_access_mode Possible values are route or ingress. If you deploy to a Kubernetes cluster other than OpenShift, the parameter must be set to ingress. route

    If the shared_configuration.sc_ingress_enable parameter is set to true, the default value is ingress.

  2. Set the resources requests and limits of each of the Decision Designer container services.
    The Decision Designer containers include:
    • mongo
    • download_service
    • git_service
    • parsing_service
    • run_service
    • credentials_service
    • front
    • embedded_build_service
    • For 21.0.1 embedded_runtime_service
    • rest_api
    Specify the values of the following parameters for each container.
    Table 2. Decision Designer containers configuration parameters
    Parameter Description
    image.repository The registry and namespace where the container images are located.
    image.tag The image tag name of the container.
    replica_count The number of desired replica of the container.
    resource.limits.memory Specifies the memory limit for the container.
    resource.limits.cpu Specifies the CPU limit for the container.
    resource.requests.memory Specifies the memory request for the container.
    resource.requests.cpu Specifies the CPU request for the container.
    For example:
    ads_configuration:
      rest_api:
        image:
          repository: "cp.icr.io"
          tag: "20.0.2"
        replica_count: "4"
        resources:
          limits:
            memory: "2G"
            cpu: "2000m"
          requests:
            memory: "512"
            cpu: "500m"
    

    For details about the default resource values of the Decision Designer container services, see System requirements.

    For details about Decision Designer configuration parameters, see Decision Designer configuration parameters.

  3. Set the resources requests and limits as well as the horizontal autoscaling of the decision runtime container service.

    Specify the values of the following parameters.

    Table 3. Decision runtime container configuration parameters
    Parameter Description
    image.repository The registry and namespace where the container images are located.
    image.tag The image tag name of the container.
    image.digest The image digest name of the container, if you prefer to use the digest instead of the tag. Digest has priority over tag.
    replica_count The number of desired replica of the container. Ignored if autoscaling.enabled is set to true. Default value is 1 in demo mode, 2 in any other installation mode.
    resource.limits.memory Specifies the memory limit for the container. Default value is 2Gi.
    resource.limits.cpu Specifies the CPU limit for the container. Default limit is 2.
    resource.requests.memory Specifies the memory request for the container. Default is 512Mi.
    resource.requests.cpu Specifies the CPU request for the container. Default is 1.
    autoscaling.enabled Specifies whether horizontal pod autoscaling is enabled or not. Default value is false in demo mode, true in any other installation mode.
    autoscaling.min_replicas Minimum number of replicas. Default value is 2.
    autoscaling.max_replicas Maximum number of replicas. Default value is 5.
    autoscaling.target_cpu_average_utilization Determines when a new pod is created, based on the value of resource.requests.cpu. Default value is 160, which means that a new pod is created when the CPU usage is more than 1.6 the value of resource.requests.cpu.
    For example, if you do NOT want to use horizontal pod autoscaling:
    ads_configuration:
      decision_runtime_service:
        image:
          repository: "cp.icr.io/ads-runtime"
          tag: "20.0.3"
        replica_count: "4"
        autoscaling:
          enabled: false
        resources:
          limits:
            memory: "2Gi"
            cpu: "2000m"
          requests:
            memory: "512Mi"
            cpu: "500m"
    
    For example, if you DO want to use horizontal pod autoscaling:
    ads_configuration:
      decision_runtime_service:
        image:
          repository: "cp.icr.io/ads-runtime"
          tag: "20.0.3"
        autoscaling:
          enabled: true
          min_replicas: 2
          max_replicas: 5
          target_cpu_average_utilization: 160
        resources:
          limits:
            memory: "2Gi"
            cpu: "2000m"
          requests:
            memory: "512Mi"
            cpu: "1000m"
    
    

    For details about the default resources values of the decision runtime container service, see System requirements.

    For details about decision runtime configuration parameters, see Decision runtime parameters
  4. Configure the event emitter.

    If you plan to integrate Automation Decision Services with IBM Business Automation Insights for visualization of decision service events in dashboards, make sure to configure security as specified in Securing communications to Kafka.

    To enable Automation Decision Services decisions to be processed by Business Automation Insights, set the decision_runtime.event_emitter.* parameters.

    When the event emitter is enabled, the Business Automation Insights management service creates an Elasticsearch index and a Kafka topic.

    A Business Automation Insights registration job calls the management service for
    • The registration of the decision runtime technical events schema in the AVRO registry so that Business Automation Insights can consume these events from Kafka.
    • The creation of the Elasticsearch index.
    The Automation Decision Services (ADS) event emitter uses an internal event queue to help buffer or throttle event emission during peak workloads. The resulting behavior of the emitter can be configured with the following parameters, all prefixed with decision_runtime.event_emitter.
    Table 4. Event emitter tuning parameters
    Parameter Description Default
    allow_missing_events Determines the behavior of the emitter when its internal queue is full:
    • If true, events are dropped as long as the queue remains full, without any performance impact on the execution of decisions.
    • If false, event emission becomes synchronous with the execution of the decision, slowing it down as a result. When the queue is no longer full, the emitter resumes its normal asynchronous behavior.
    In all cases, failure to emit an event does not prevent the execution of a decision.
    true
    queue_capacity The maximum number of events that can be contained in the emitter internal queue. When this capacity is reached, then the behavior of the emitter is determined by the value of the parameter allow_missing_events. 50,000
    dequeuer_threads Specifies how many threads poll the events queue to send the events to the kafka topic. If this parameter is not set, the number of threads is computed at the start of the decision runtime and based on the number of CPU allocated to the runtime.
    Note: If you disable the emitter later on, both the Elasticsearch index and the Kafka topic remain. This way, unprocessed events, if they exist, are not lost. If you do not want to keep this data after disabling the emitter or uninstalling Automation Decision Services, it is the cluster admin's responsibility to delete the Elasticsearch index and Kafka topic.
  5. Set any other configuration parameters in the custom resource YAML file. Refer to Preparing to install Automation Decision Services where you might have defined important settings such as secrets, certificates, persistent volumes, as well as Machine Learning providers.
    Note: All the parameters mentioned in this page can be found under the ads_configuration section of the custom resource (CR) file.
    For a complete list of configuration parameters, see Automation Decision Services configuration parameters