Workload API configuration¶

The Workload API schedules each Workload's container groups onto a resource bundle (runtime.containerGroups[].resourceBundles). A bundle is only eligible for this if its use_cases list includes "workload"—bundles that support other use cases (for example, customModel) are not automatically available to the Workload API.

Default bundles¶

The CPU and GPU resource bundles that ship with DataRobot by default (for example, cpu.medium, cpu.5xlarge, and the default GPU bundles) already include "workload" in their use_cases. No configuration is required to use these out of the box.

Adding custom resource bundles¶

If you configure custom resource bundles for your installation—for example, following the GPU bundle configuration described in Custom Models Configuration—those bundles are not eligible for Workloads unless you explicitly add "workload" to each bundle's use_cases.

This applies to any of the environment variables that define resource bundles: LRS_CPU_CONTAINER_SIZES, LRS_GPU_CONTAINER_SIZES.

core:
  config_env_vars:
    LRS_GPU_CONTAINER_SIZES: |-
      [
        {
          "id": "gpu.medium",
          "name": "GPU - M",
          "description": "1 x NVIDIA A10 | 24GB VRAM | 8 CPU | 32GB RAM",
          "gpu_maker": "nvidia",
          "gpu_type_label": "nvidia-a10g-1x",
          "gpu_count": 1,
          "gpu_memory_mb": 24576,
          "cpu_count": 8,
          "memory_mb": 32768,
          "use_cases": ["customModel", "workload"]
        }
      ] 

In this example, gpu.medium supports both Custom Models and Workloads because its use_cases list includes both customModel and workload. A bundle that should serve Workloads exclusively only needs "use_cases": ["workload"].

Verify bundle availability¶

After updating a bundle's configuration, confirm it's visible to the Workload API by querying the compute bundles endpoint with the workload use case:

curl -s "${DATAROBOT_ENDPOINT}/mlops/compute/bundles/?useCases=workload" \
  -H "Authorization: Bearer ${DATAROBOT_API_TOKEN}" 

A bundle you've added or updated should appear in the response before you reference its id in runtime.containerGroups[].resourceBundles.

備考： - Adding a bundle to use_cases for another purpose (such as customModel) does not make it eligible for Workloads—"workload" must be listed explicitly.

Image URI validation¶

The Workload API can check a container's imageUri against an allowlist and a denylist of glob patterns when an artifact is created, updated, or cloned.

Configuration lives under the imageUriValidation key: an enabled flag, an allowlist, and a denylist.

enabled¶

• Type: bool. デフォルト：false。
• When false, no imageUri is checked or blocked—the feature is a no-op regardless of what allowlist/denylist contain.
• When true, every container imageUri is checked against allowlist and denylist.

imageUriValidation:
  enabled: false 

allowlist and denylist¶

• Both are lists of glob (fnmatch-style, * wildcard) patterns matched against the image URI.
• denylist takes priority over allowlist—a URI matching any denylist pattern is rejected even if it also matches allowlist.
• A URI that doesn't match denylist must match at least one allowlist pattern to be accepted; otherwise it's rejected.
• Before matching, DataRobot strips any tag (:tag) or digest (@sha256:...), normalizes Docker Hub short forms to their canonical docker.io/... form (for example, alpine and library/alpine both normalize to docker.io/library/alpine), and lowercases the registry host. Host matching is therefore case-insensitive (MyRegistry.AzureCR.io and myregistry.azurecr.io are equivalent); the image path and tag remain case-sensitive.

The base chart (values.yaml) ships the following defaults, which apply on every cluster unless an overlay overrides them:

imageUriValidation:
  enabled: false
  allowlist:
    - "docker.io/*"
    - "*.docker.io/*"
    - "quay.io/*"
    - "ghcr.io/*"
    - "public.ecr.aws/*"
    - "registry.gitlab.com/*"
    - "*.jfrog.io/*"
    - "nvcr.io/*"
  denylist:
    - "*.dkr.ecr.*.amazonaws.com/*"   # AWS ECR (private)
    - "*.azurecr.io/*"                # Azure ACR
    - "gcr.io/*"                      # GCP GCR
    - "*.gcr.io/*"                    # GCP GCR (regional hosts, e.g. us.gcr.io)
    - "*.pkg.dev/*"                   # GCP Artifact Registry
    - "docker.io/datarobot/*"
    - "docker.io/datarobotdev/*"
    - "*.docker.io/datarobot/*"
    - "*.docker.io/datarobotdev/*" 

Configure per cluster¶

allowlist and denylist are only declared once, in the base chart—an overlay inherits both as-is unless it explicitly overrides one.

Helm replaces list values entirely rather than merging them, so overriding allowlist or denylist means re-declaring the full list you want, not just the entries you're adding or removing. For example, to keep every default denylist entry except the two datarobotdev globs:

imageUriValidation:
  enabled: true
  denylist:
    - "*.dkr.ecr.*.amazonaws.com/*"
    - "*.azurecr.io/*"
    - "gcr.io/*"
    - "*.gcr.io/*"
    - "*.pkg.dev/*"
    - "docker.io/datarobot/*"
    - "*.docker.io/datarobot/*"
    # datarobotdev/* intentionally omitted 

To permit an additional registry, add it to allowlist alongside the existing entries:

imageUriValidation:
  enabled: true
  allowlist:
    - "docker.io/*"
    - "*.docker.io/*"
    - "quay.io/*"
    - "ghcr.io/*"
    - "public.ecr.aws/*"
    - "registry.gitlab.com/*"
    - "*.jfrog.io/*"
    - "nvcr.io/*"
    - "registry.example.com/*"