Configuring the ordering of TCO Optimizer policy processing

Order TCO policies by using the UI

To manage the execution order of TCO policies in the UI:

1. Open the IBM Cloud Logs dashboard for your logging instance.

2. Click the Data Pipeline icon .

3. Click TCO Optimizer.

4. Drag the policies to reorder the list of policies. The policy execution order is changed to reflect the new sequence. The execution order of policies in the list corresponds to their visual arrangement in the UI.

Order TCO policies by using the API

In the API, policy ordering is done by using the request payload argument before in the policy create or policy update methods.

The before argument determines the unique ID of the policy before which the policy is created or updated.

• If before is provided with a valid unique ID of an existing policy, the policy is created or updated and placed in processing order before the policy with the provided ID.

• If before is Empty(""), the policy is added as the last policy in the processing list.

• If before is provided with ID of policy that doesn't exist, the API returns an error.

The order value in the API response returns the policy's order in the processing list. To get a list of all defined policies and their order values, use the Get policies method.

The following JSON is an example of the before field:

    "before": {
        "id": "uuid of policy"
    }

The following curl example assumes that you have a single existing IBM Cloud Logs policy A with the ID 9fab83da-98ce-4f18-a7ba-c6f0435cd673. The example creates a policy that is named example_policy before policy A, which creates the example_policy order as 1 and the order of policy A is updated to 2.

curl -X POST --location --header "Authorization: Bearer ${iam_token}" --header "Accept: application/json" --header "Content-Type: application/json" --data   '{
    "application_rule": {
      "name": "policy-test",
      "rule_type_id": "is"
    },
    "before": {
      "id": "9fab83da-98ce-4f18-a7ba-c6f0435cd673"
    },
    "deleted": false,
    "description": "Example policy description",
    "enabled": true,
    "log_rules": {
      "severities": ["error"]
    },
    "name": "example_policy",
    "order": 2,
    "priority": "type_high",
    "subsystem_rule": {
      "name": "policy-test",
      "rule_type_id": "is"
    }
  }' "${base_url}/v1/policies"

Order TCO policies by using the CLI

Before you begin, follow the steps to set your IBM Cloud Logs instance API endpoint.

To order TCO policies by using the IBM Cloud Logs CLI plug-in, run the ibmcloud cloud-logs policy-create command and specify the before argument.

For example, the following CLI command assumes that you have a single existing IBM Cloud Logs policy A with the ID 9fab83da-98ce-4f18-a7ba-c6f0435cd673. The example creates a policy that is named example_policy before policy A, which creates the example_policy order as 1 and the order of policy A is updated to 2.

ibmcloud cloud-logs policy-create \
--prototype '{"name": "example_policy", "before": {"id": "9fab83da-98ce-4f18-a7ba-c6f0435cd673"}, "description": "example policy decription", "priority": "type_high", "application_rule": {"rule_type_id": "is", "name": "test"}, "subsystem_rule": {"rule_type_id": "is", "name": "test"},"enabled": true, "log_rules": {"severities": ["critical"]}}'

Order TCO policies by using Terraform

Ordering of TCO policies is done in Terraform by using the before argument of the ibm_logs_policy resource.

For example, the following Terraform resource assumes that you have a single existing IBM Cloud Logs policy A with the ID 9fab83da-98ce-4f18-a7ba-c6f0435cd673. The example creates a policy that is named example_policy before policy A, which creates the example_policy order as 1 and the order of policy A is updated to 2.

resource "ibm_logs_policy" "logs_policy_instance" {
  instance_id = "<guid of cloud logs instance>"
  region      = "<region of cloud logs instance>"
  name        = "example_policy"
  description = "example policy decription"
  priority    = "type_medium"
  application_rule {
    name         = "otel-links-test"
    rule_type_id = "start_with"
  }
  log_rules {
    severities = ["info"]
  }
  before {
    id =  "9fab83da-98ce-4f18-a7ba-c6f0435cd673"
  }
}

State differences

When you order TCO policies by using Terraform, you need to consider state differences.

Terraform shows state differences during a subsequent apply if there is an update to the before field by the API due to the creation or modification of policies during a previous terraform apply.

For example, consider where you try to create policy3 between policy1 and policy2. When policy3 is inserted between policy1 and policy2:

• The order value of policy1 is 1 and policy2 is updated from 2 to 3 by the API.

• The before value of policy1 is updated to id of policy3 and the before value of policy2 remains same as it is since it is still the last policy.

• Since order is a response attribute in the API and in the Terraform resource, the state is updated without any diff.

• However, before is a request parameter, which is something the user provides in their resource block.

  During subsequent runs of plan and apply, Terraform refreshes the state and the before of policy1 is updated to id of policy3.

  Therefore, Terraform apply shows state diff since the user has before of policy1 as id of policy2 in their Terraform resource but state has the id of policy3.

  You need to update your TF file and update your resources with the correct before value before you run apply again to avoid state differences. Otherwise, Terraform recognizes a state difference and tries to apply unexpected changes.

An error is not returned when a state difference occurs because it is not possible to reliably determine whether the detected change is intentional or a side effect of a previous apply operation. Since updates are applied based on the before state, differences between expected modifications and unintended drift cannot be determined. Instead of an error, a state difference (diff) is returned instead.