Configuration management for Orchestration Pipelines

The configuration management provides centralized configuration capabilities for Orchestration Pipelines. It exposes a protobuf-based gRPC API with a REST interface (via grpc-gateway) and supports multi-tenant environments. The service supports multi-tenant environments and enforces consistent configuration across system, tenant, and asset container scopes.

Configuration resolution model

Configuration values are evaluated using a strict and deterministic precedence order. The system does not merge values across scopes. Resolution order: Asset container settings (project-level override) Tenant settings (default values for the tenant) Built-in system defaults The first defined value in this sequence is returned and used.

Example: Resolution of default_pipeline_job_name_suffix

  • If the asset container defines a value, that value is returned.
  • If the asset container does not define a value and the tenant defines one, the tenant value is returned.
  • If neither defines a value, the system returns the default:
".Pipeline job"

Tenant-Level Resolution

Tenant settings do not inherit from other tenants or systems:

  • If a value is explicitly stored, that value is returned.
  • If no value is stored, a predefined default is returned.

Default values and initial system state

For a new installation, the system initializes with predefined defaults. No tenant-specific overrides exist at this stage. The following defaults apply:

  • default_pipeline_job_name_suffix = ".Pipeline job"
  • nested_job_execution_mode = INDEPENDENT_JOBS_MODE

Default asset container configuration:

{
  "allowed_operational_scope": "WIDE_SCOPE",
  "resource_reference_type": "EXACT_BY_ID",
  "pipeline_save_mode": "AUTO_SAVE",
  "jobs_deletion_mode": "LEAVE_ORPHAN_JOBS",
  "runner_type": "PIPELINE_RUNNER",
  "nested_job_execution_mode": "INDEPENDENT_JOBS_MODE",
  "default_pipeline_job_name_suffix": ".Pipeline job"
}

API endpoints for retrieving configuration data

The service exposes REST endpoints that mirror the underlying gRPC API.

Retrieve tenant settings

GET /apis/v1/tenant_settings

Returns all tenant-level configuration values.

Retrieve asset container settings

GET /apis/v1/asset_container_settings?project_id=<project_id>

Returns configuration for the specified asset container. If a setting is not defined at this level, the effective value must be resolved using the defined hierarchy.

Command-line interface for managing tenant settings

Tenant settings are available through the cpdctl CLI starting from version 1.8.227.

Retrieving tenant settings using CLI

cpdctl pipeline get-settings [setting_name_or_prefix]

Behavior:

  • If no argument is provided, the command returns all tenant settings.
  • If a prefix is provided, the command returns all matching settings.
  • If a full setting name is provided, the command returns a single value.

Examples:

cpdctl pipeline get-settings

cpdctl pipeline get-settings default_pipeline_settings

cpdctl pipeline get-settings default_pipeline_settings.appearance.auto_save_frequency

You can use the optional flag --description, which displays setting descriptions in addition to values.

Updating tenant settings using CLI

Use following command if you want to update tenant settings:

cpdctl pipeline update-settings [setting_name_or_prefix] value

The following formats are supported:

  • Inline JSON:
cpdctl pipeline update-settings \
'{"default_asset_container_settings":{"allowed_operational_scope":"WIDE_SCOPE"}}'
  • File-based input:
cpdctl pipeline update-settings @tenant-settings.json
  • Scoped update using a file:
cpdctl pipeline update-settings default_pipeline_settings @default-pipeline-settings.json

Updating a single setting with multiple values

If you want to update a single setting, run this command:

cpdctl pipeline update-settings \
default_pipeline_settings.execution_cache.caching_conditions \
RETRY_ON_FAILURE,PIPELINE_UNCHANGED,INPUTS_UNCHANGED

Validation and compatibility

Validation Rules

Each setting enforces strict validation rules:

  • Enumerated settings accept only predefined values.
  • List-based settings accept only supported list members.
  • Invalid input results in a rejected request.

The service does not apply partial updates. Invalid payloads are rejected without modifying existing values.

Compatibility and Extensibility

The service supports backward-compatible extensions:

  • New settings can be introduced without impacting existing clients.
  • Clients ignore unknown fields returned by the API.
  • Protobuf schema evolution ensures compatibility across versions.