DynamoGraphDeploymentRequest (DGDR) Reference

A DynamoGraphDeploymentRequest (DGDR) is Dynamo’s deploy-by-intent generator for DynamoGraphDeployment (DGD) resources. You describe what you want to run and your performance targets; the profiler determines a configuration and produces the DGD that serves traffic.

For the task-oriented walkthrough — authoring a request step by step — see Auto Deploy with DGDR. For ready-to-copy manifests, see DGDR Templates.

This page documents the nvidia.com/v1beta1 API — the storage version.

Conversion views

When the nvidia.com/v1beta2 API is served, the API server represents a native v1beta2 request through v1alpha1 or v1beta1 by populating spec.v1beta2. Conversely, it represents a native v1beta1 request through v1beta2 by populating spec.v1beta1. These fields are read-only conversion views. Create and modify a request through the API version that owns its native fields; do not set or edit the conversion field directly. An unchanged conversion view can be written back without changing the stored request.

v1beta2 hardware SKU

spec.hardware.gpu.sku in nvidia.com/v1beta2 is an open string containing an AISimulate system-catalog identifier. The AISimulate release bundled with this Dynamo release includes a100_pcie, a100_sxm, a30, b200_sxm, b300_sxm, b60, gb200, gb300, h100_pcie, h100_sxm, h200_sxm, l4, l40s, and rtx_pro_6000_server.

Admission passes an explicit SKU through unchanged. It warns when the bundled catalog does not contain that identifier, but does not reject it: an external AISimulate systems catalog may provide additional identifiers.

Omit hardware to let admission discover and persist sku, budget, and numGpusPerNode. An exactly empty hardware: {} object opts out of all operator cluster and DCGM discovery and typed hardware defaults. Any nonempty object, including hardware: {gpu: {}}, is partial hardware intent: admission discovers and persists each missing field while preserving every explicit value. The Run controller never performs hardware discovery.

Set all three values to bypass discovery with fully explicit hardware. An unknown SKU must provide both budget and numGpusPerNode, because admission cannot map that identifier to cluster capacity or topology.

apiVersion: nvidia.com/v1beta2
kind: DynamoGraphDeploymentRequest
metadata:
  name: future-accelerator
spec:
  model:
    name: Qwen/Qwen3-0.6B
  hardware:
    gpu:
      sku: future_accelerator # Passed to AISimulate unchanged; admission warns if unknown.
      budget: 8
    numGpusPerNode: 8        # Completes explicit hardware; admission performs no discovery.

To leave the complete hardware input to AISimulate and inputOverrides, use the empty-object opt-out and supply both the upstream hardware selector and candidate GPU budget yourself. Request and Run admission validate the merged input against the bundled AISimulate input schema. Run specs remain immutable; unchanged specs remain metadata-updatable after a bundled schema change.

spec:
  hardware: {}
  aisim:
    inputOverrides:
      engine:
        hardware: h200_sxm
      optimization:
        constraints:
          max_candidate_gpus: 8

v1beta2 DGD Overrides

Experimental; for development only. Enable dynamo-operator.dgdrV1Beta2.enabled in the platform Helm chart to use spec.overrides.dgd. It accepts one partial nvidia.com/v1beta1 DGD, applied to every selected Candidate across backends and topologies. Other DGD API versions are not accepted here.

Overrides follow the DGD schema’s Server-Side Apply merge rules. For example, components and named containers merge by name; container command and args are atomic lists and replace the entire generated list. These are examples: the schema’s map, set, and atomic markers determine how all fields merge. Omitted fields retain their generated values.

The existing DGD $patch: {args: append} customization is also supported on a named container. It appends the supplied arguments to an explicit generated args list and removes the directive before validation. Both the target container and its args must already exist. This is the only supported $patch operation.

apiVersion: nvidia.com/v1beta2
kind: DynamoGraphDeploymentRequest
metadata:
  name: custom-worker-image
spec:
  model:
    name: Qwen/Qwen3-0.6B
  backends: [vllm] # OPTIONAL; restricts results to this backend.
  overrides: # OPTIONAL; omitted means no DGD override.
    dgd: # OPTIONAL; partial DGD resource.
      apiVersion: nvidia.com/v1beta1 # REQUIRED when dgd is set.
      kind: DynamoGraphDeployment # REQUIRED when dgd is set.
      metadata:
        labels:
          workload: customized
      spec:
        components:
          - name: worker
            podTemplate:
              spec:
                containers:
                  - name: main
                    image: registry.example/runtime:1.7.0

The override is frozen into the immutable Run spec and applied atomically: if a target component is absent or any part cannot be applied, the Candidate retains the unchanged generated DGD spec and reports Valid=False. A new named container can be added to an existing component through the normal merge; $patch: {args: append} requires an existing container instead. For example, a decode override can fail for an aggregated Candidate whose topology contains only worker. No subset of a failed override is applied.

Choose target names that exist in the results you want to keep. Restricting backends can avoid engine-specific mismatches, but does not guarantee a particular topology. A shared decode override can invalidate every aggregated result, including the entire result set. Invalid Candidates still count toward recommendation.maxCandidates and do not trigger replacement searches.

After a successful merge, a copy of the DGD undergoes strict server-side dry-run creation, including DGD defaults, schema, CEL, and validating webhooks. The dry-run response is discarded; the stored payload remains the one from before the check. Unknown fields and incorrect field types remain visible on invalid Candidates; Valid=False records the failure. Infrastructure failures are retried instead of being recorded as an invalid deployment.

Retryable Candidate preparation errors are visible on the Run as Published=False, reason PublicationBlocked, with the error in the condition’s message. This includes HTTP 403 from a DGD dry-run: RBAC changes propagate asynchronously, and a permission or policy configuration can be repaired. The publisher keeps retrying and preserves the already published Candidate references and progress. Once publication succeeds, it sets Published=True with reason PublicationSucceeded. Published is owned by the publisher; the Run controller independently owns Completed. Changing the request’s spec stops the old Run and its publisher before starting the replacement Run.

For example, the Run can report this status while retrying a denied DGD dry-run:

status:
  conditions:
    - type: Published
      status: "False"
      reason: PublicationBlocked
      message: "DGD dry-run forbidden: exceeded namespace quota"
      observedGeneration: 1
      lastTransitionTime: "2026-11-04T18:00:00Z"

Candidate.spec contains exactly the DGD spec, including backendFramework. DGD labels and annotations are copied to Candidate metadata. If an override fails to apply, only the original generated labels and annotations are copied; metadata from the failed override is discarded. If the merge succeeds but dry-run validation fails, the override’s labels and annotations remain on the invalid Candidate. An override that makes the complete Candidate metadata invalid is rejected in full. The total annotation-size limit includes generated annotations and the reserved annotations added to the Candidate.

Candidate identity, including name, namespace, and owner references, cannot be overridden. The following metadata is also reserved; attempts to override it fail atomically:

• Labels nvidia.com/dgdr-run-uid and nvidia.com/dgdr-candidate-id.
• Annotation dgdr.nvidia.com/additional-resources.
• Annotations with the nvidia.com/dgd- conversion-bookkeeping prefix.

Evaluation parameters, metrics, and the final Valid condition belong to Candidate status. The condition’s statuses and reasons are documented on DynamoGraphDeploymentCandidateStatus.conditions.

apiVersion: nvidia.com/v1beta2
kind: DynamoGraphDeploymentCandidate
metadata:
  name: example-candidate
spec: # Immutable, opaque DGD spec; preserved even when validation fails.
  backendFramework: vllm
  components:
    - name: frontend
      type: frontend
      replicas: 1
      podTemplate:
        spec:
          containers:
            - name: main
              image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:1.7.0
    - name: worker
      type: worker
      replicas: 1
      podTemplate:
        spec:
          containers:
            - name: main
              image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:1.7.0
              args: [--model, Qwen/Qwen3-0.6B]
status:
  parameters: # Original resolved simulation inputs.
    tp: 2
  metrics: # Original simulation results; not recomputed after overrides.
    throughput: 12.5
  conditions:
    - type: Valid
      status: "True"
      reason: ValidationSucceeded
      message: Strict DGD dry-run succeeded
      observedGeneration: 1
      lastTransitionTime: "2026-10-30T12:00:00Z"

Overrides may change model, backend, GPU allocation, parallelism, images, or arguments. The original simulation parameters and metrics are not a performance prediction for the overridden DGD.

List only Candidates with Valid=True in the current namespace (requires jq):

kubectl get dynamographdeploymentcandidates -o json \
  | jq -r '.items[] | select(any(.status.conditions[]?; .type == "Valid" and .status == "True")) | .metadata.name'

Invalid Candidates count toward recommendation.maxCandidates and retain their original search order in Run references. They do not trigger replacement searches. A successful Run requires a successful search and at least one Valid=True Candidate; when all selected Candidates are invalid, the Run fails and keeps them for diagnosis.

Spec reference

Only model is unconditionally required by the schema. Admission rejects a new DGDR whose supplied spec.image has no parseable semantic-version tag unless spec.runtimeVersionOverride is set. When spec.image is omitted, the operator supplies a versioned default as described below.

Profiler image version compatibility

When spec.image is omitted, the operator defaults it on creation to nvcr.io/nvidia/ai-dynamo/dynamo-planner:<operatorVersion>. The operator requires operatorVersion to be valid semantic versioning, so the default image has a parseable version tag.

The DGDR-level spec.runtimeVersionOverride supplies a default for generated DGD components. After the profiler materializes the DGD and applies spec.overrides.dgd, the operator copies the DGDR value only to components that do not already have an explicit override. This behavior applies across profiler versions. Profilers through Dynamo 1.3.0 may discard the field while parsing the DGDR, but the operator reapplies the default from the stored DGDR.

Set spec.runtimeVersionOverride when an effective generated component runtime image uses a non-semantic-version tag or digest, or when its tag does not identify the intended Dynamo runtime version. The DGDR value also covers images replaced through spec.overrides.dgd when that component does not set its own runtimeVersionOverride. An explicit component-level value takes precedence.

While a DGDR has autoApply: false, you may set or change runtimeVersionOverride during Profiling or Ready. After it reaches Ready, you may enable autoApply, either separately or while changing the override. The operator applies the current value while creating the new DGD. These updates do not modify status.profilingResults.selectedConfig or the nvidia.com/generated-dgd-spec annotation. Other spec updates remain forbidden after profiling starts.

When the DGDR-level field is unset, each effective generated DGD component follows the component runtime version rules independently. An overridden runtime image without a parseable semantic-version tag requires runtimeVersionOverride on that component.

Profilers through Dynamo 1.3.0 discard the embedded DGD override’s apiVersion and kind, then directly merge the remaining dictionary into a generated v1alpha1 DGD. Raw storage preserves the override fields but does not convert between DGD schemas. Use a v1alpha1-shaped override under spec.services; a v1beta1 spec.components override is not translated into the generated service.

Overrides

Planner

spec.features.planner is a PlannerConfig object, passed through to the Planner service without field-level validation; the Planner validates it at startup. Setting it (non-null) enables the planner in the generated DGD. The same object is documented standalone at Planner Configuration; its fields are reproduced here. Nested list-and-object types are expanded under Additional Types. All fields are optional.

Core settings

Optimization target

Performance model and pre-deployment sweeping

GPU budget

Throughput-based scaling

Load-based scaling

Load prediction

Prometheus metrics

These fields default from environment variables and are excluded from serialized output.

Advisory and diagnostics

Scheduling and plugin pipeline

Generated DGD overrides

spec.overrides.dgd is a partial, versioned DGD. It does not define or extend the profiler’s candidate topology. Thorough profiling merges the override into each generated benchmark candidate before measurement and into the interpolation deployment. Every search strategy merges it into the final generated DGD. Use apiVersion: nvidia.com/v1beta1 and kind: DynamoGraphDeployment for new overrides. Components, pod-template containers, and container environment variables merge by name; atomic lists such as graph-level spec.env and container args replace their generated values.

To permit custom model repository code without depending on the selected topology, set spec.overrides.trustRemoteCode: true. The profiler applies --trust-remote-code to every generated vLLM or SGLang worker after the component topology is known. Enable this setting only for model repositories you trust.

Generated component names

An entry in spec.overrides.dgd.spec.components must use the exact, case-sensitive component name from the generated DGD. These are DGD component names, not Kubernetes Service resource names. The current profiler templates generate these components:

Setting spec.features.mocker.enabled: true replaces the inference workers with decode and prefill mocker components. Setting spec.features.planner adds a Planner component.

Add overrides before profiling starts. The DGDR spec becomes immutable during profiling, so you cannot inspect selectedConfig and then add overrides to the same resource. To inspect the names generated by a specific Dynamo release, follow the discovery workflow, then recreate the DGDR with the required overrides.

For example, set an environment variable on one generated component:

apiVersion: nvidia.com/v1beta1
kind: DynamoGraphDeploymentRequest
metadata:
  name: qwen3-sglang
spec:
  model: Qwen/Qwen3-30B-A3B
  backend: sglang
  overrides:
    dgd:
      apiVersion: nvidia.com/v1beta1
      kind: DynamoGraphDeployment
      spec:
        components:
        - name: decode
          podTemplate:
            spec:
              containers:
              - name: main
                env:
                - name: TRITON_PTXAS_PATH
                  value: /usr/local/cuda/bin/ptxas

Overrides can modify only components present in the generated DGD. An unresolved spec.components or spec.services name causes DGD materialization to fail. A recognized deprecated name may be translated to the corresponding component in the selected topology with a warning. An override cannot add deployment topology. Labels and annotations merge, metadata.name selects the final DGD name, and other identity metadata is ignored. status, null values for typed fields, and field deletion are not supported.

To add flags to a container already present in the generated DGD, set $patch.args to append on that named container:

spec:
  overrides:
    dgd:
      apiVersion: nvidia.com/v1beta1
      kind: DynamoGraphDeployment
      spec:
        components:
        - name: Frontend
          podTemplate:
            spec:
              containers:
              - name: main
                $patch:
                  args: append
                args:
                - --router-mode
                - kv

The only supported modifier is args: append, and its args list must contain at least one non-empty string. The target container and its args list must already be present in the generated blueprint. The profiler blueprints define the complete default CLI for Frontend/main, so the example preserves python3 -m dynamo.frontend and appends the KV router flags. The override helper combines the argument lists and removes $patch before returning the final DGD. Without $patch, specifying args retains the standard replacement behavior and requires the complete desired list.

For worked examples, see DGDR Templates. For router configuration and EPP topologies, see the Router Guide and Gateway API Inference Extension.

SKU format

hardware.gpuSku uses lowercase underscore format (h100_sxm, not H100-SXM5-80GB). When gpuSku is omitted, the operator normalizes the discovered GPU product name (for example, NVIDIA B300 SXM6 AC) to the matching value (b300_sxm). The observed Vera Rubin product name NVIDIA VR NVL72 ES and its GPU Feature Discovery form NVIDIA-VR-NVL72-ES map to the canonical AISimulate identifier vr_nvl72. GB200 discovery uses the canonical AISimulate identifier gb200:

spec:
  hardware:
    gpuSku: gb200

Status

The operator maintains observed state under status. See Lifecycle for how phase and profilingPhase progress, and for the full condition-type list.

Additional Types

Nested struct types referenced by the fields above, broken out here to keep the field lists shallow. Types prefixed batch/v1., metav1., or runtime. are standard Kubernetes types and link to their Go package documentation instead of being expanded.

ParetoConfig

Deprecated compatibility type for status.profilingResults.pareto. Current profiling runs do not populate this type.

PickedParallelConfig

A parallelism pick emitted by AIConfigurator. Referenced by AICInterpolationSpec.

AICInterpolationSpec

Everything the Planner needs to reproduce a rapid-mode AIC sweep. Written by the profiler onto the Planner ConfigMap; not normally hand-authored. Referenced by features.planner.aic_interpolation.

ExternalPluginEntry

One static external-plugin registration under features.planner.scheduling.external_plugins. Rejects unknown fields.

InProcessPluginSpec

One in-process plugin under features.planner.plugin_registration.in_process_plugins. Rejects unknown fields.

Lifecycle

When you create a DGDR, it progresses through these phases (status.phase):

Conditions

The operator maintains these conditions on status.conditions:

Monitoring

# Watch phase transitions
kubectl get dgdr my-model -n $NAMESPACE -w
# Detailed status, conditions, and events
kubectl describe dgdr my-model -n $NAMESPACE
# Profiling sub-phase
kubectl get dgdr my-model -n $NAMESPACE -o jsonpath='{.status.profilingPhase}'
# Profiling job logs
PROFILING_JOB=$(kubectl get dgdr my-model -n "$NAMESPACE" -o jsonpath='{.status.profilingJobName}')
kubectl logs -f "job/${PROFILING_JOB}" -c profiler -n "$NAMESPACE"
# View generated DGD spec (when autoApply: false)
kubectl get dgdr my-model -n $NAMESPACE \
  -o jsonpath='{.status.profilingResults.selectedConfig}' | python3 -m json.tool

Resource ownership

• The DGDR does not set an owner reference on the DGD it creates. Deleting a DGDR does not delete the DGD — it persists independently so it can continue serving traffic.
• The relationship is tracked via labels: dgdr.nvidia.com/name and dgdr.nvidia.com/namespace.
• Additional resources (planner ConfigMaps) are created in the same namespace and labeled with dgdr.nvidia.com/name.

Replay a recorded trace (v1beta2)

A native v1beta2 request can evaluate every candidate against a recorded request trace instead of synthetic traffic. Set spec.workload.trace instead of spec.workload.static; the two are mutually exclusive, and admission adds no static default when trace is set. To switch an existing request from static traffic to a trace, set spec.workload.static to null in the same update.

apiVersion: nvidia.com/v1beta2
kind: DynamoGraphDeploymentRequest
metadata:
  name: qwen3-trace-replay
spec:
  model:
    name: Qwen/Qwen3-0.6B
  workload:
    trace:
      # format defaults to Dynamo
      source:
        persistentVolumeClaim:
          claimName: request-traces           # PersistentVolumeClaim in this namespace
          subPath: windows/2026-10-27T10-00.jsonl.gz
      replay:
        arrivalSpeedupRatio: 1.0              # optional; 2.0 replays arrivals twice as fast

Before you create the request:

• Create the PersistentVolumeClaim in the request’s namespace. Use a filesystem volume, not volumeMode: Block. When the process that writes the trace keeps running, use ReadWriteMany. With ReadWriteOnce, a Job scheduled to another node than the writer waits in ContainerCreating, and with ReadWriteOncePod, a Job waits in Pending until the writer’s pod is gone. The Run reports Running while its Job waits.
• Finish writing the file. subPath names one file relative to the claim root; directories and globs are not expanded. Every Run of the request reads the file when its Job starts, so do not rewrite it afterwards. To replay several rolled jsonl_gz segments, concatenate them into one .jsonl.gz file. A relative symlink to another file in the claim works. An absolute symlink does not, because the kubelet resolves it on the node rather than inside the claim, and neither does a symlink that leaves the claim.
• Make the file readable by others (for example, mode 0644 in 0755 directories) or by group 65532, which the Job’s pod has as a supplemental group. The pod sets no fsGroup, so neither the kubelet nor a CSI driver changes the ownership or permissions of anything on the claim.

The operator mounts only this file, read-only and only into the AISimulate container, through a subPath of the claim at /var/run/aisimulate/trace/trace.jsonl.gz, or at /var/run/aisimulate/trace/trace.jsonl when subPath does not end in .gz. The kubelet resolves subPath inside the claim and refuses to mount a file outside it. If the file does not exist when the Job starts, the kubelet cannot mount it either, and the AISimulate container waits; see Trace claim lifecycle. On a volume type whose node directory the kubelet can write, such as hostPath, the kubelet instead creates an empty directory at subPath on the claim, and the Run fails when AISimulate cannot read it.

format defaults to Dynamo, the only supported format. It reads the Dynamo request trace (dynamo.request.trace.v1) written by the frontend, as JSON Lines or as gzip-compressed JSON Lines when the file name ends in .gz. See the Request Trace Reference.

The operator lowers the trace to the AISimulate input traffic.source (type: trace, format: dynamo, and paths with the mounted file) and traffic.load.type: trace_timestamps, with traffic.load.speedup when arrivalSpeedupRatio is set. It adds no traffic.stop.requests. These values are an underlay, like every value lowered from a typed field: spec.aisim.inputOverrides is applied last as a JSON Merge Patch and can replace any of them, including traffic.source.type, traffic.source.format, and traffic.source.paths. A null override deletes the named field or parent object, and the operator does not restore it. For example, this override deletes the lowered source:

spec:
  aisim:
    inputOverrides:
      traffic:
        source: null

The typed persistentVolumeClaim source alone decides which claim the Run’s Job mounts and which claim the Run protects. Overriding traffic.source.paths adds no volume mount. AISimulate validates the resulting input when the Run’s Job starts, and an input it rejects fails the Run; admission does not validate it against the AISimulate schema yet.

Trace claim lifecycle

The operator ties the claim’s lifetime to the Runs that read it. It decides from structured state only: the claim’s deletionTimestamp, volumeMode, and phase, the Job’s conditions, and the request’s spec. It copies container status messages into the Run but never interprets them.

• Protection. Before a Run creates its Job, the operator adds the finalizer nvidia.com/dgdr-run-<run-uid> to the claim, where <run-uid> is the Run’s metadata.uid. Every Run that reads the claim adds its own finalizer, so Runs of several requests can share a claim. The operator removes a Run’s finalizer once the Run is complete and none of its Jobs is still running, or once the Run and its Jobs are deleted, for example when the request retires old Runs or is deleted. Kubernetes garbage collection deletes the Job of a deleted Run before the Job’s pod has stopped, so the finalizer of a Run deleted before it completed can be removed while that pod still mounts the file; kubernetes.io/pvc-protection keeps the claim until the pod is gone.
• Deleting the claim cancels its Runs. When the claim has a deletionTimestamp, the operator stops the Job of every Run that reads it through foreground deletion, whether or not the Job’s pod has started. Once the Job and its pod are gone, the Run fails with reason TraceSourceDeleted, and the operator then removes the Run’s finalizer. A Job that already completed or failed before the claim’s deletion, and is not itself being deleted, is not stopped; its own outcome decides the Run. Once the operator has started stopping a Job, the Run fails with TraceSourceDeleted even if the Job is marked failed while its pod is removed. A Run whose claim is already being deleted before it creates its Job fails with TraceSourceDeleted without creating anything.
• A missing claim keeps the Run open. When the claim does not exist, the Run stays Pending with Completed=False and reason TraceSourceMissing, and starts once you create the claim.
• A claim no Job can mount fails the Run before it starts. Before the Run creates its Job, a volumeMode: Block claim or a claim in phase Lost fails the Run with reason TraceSourceUnavailable. After the Job exists, the operator does not check the claim’s volume mode or phase again; the Job’s pod waits until the volume is usable, the Job fails, or you cancel the Run.
• A waiting container is a diagnostic, not a failure. While a container of the Run’s Job waits on an error, such as a trace file the kubelet cannot mount (a missing file, an absolute symlink, or a symlink that leaves the claim) or an image it cannot pull, the Run stays open with Completed=False, reason ContainerWaiting, and the message container "<name>" is waiting: <reason>: <message>, where <reason> and <message> are copied from the container’s status. The operator does not delete the Job, and there is no timeout. The kubelet keeps retrying the container, so fixing the cause, for example writing the missing file, lets the same Run continue. Waiting in ContainerCreating or PodInitializing is not reported: volume errors that keep a pod there, such as a ReadWriteOnce claim attached to another node, appear only in the pod’s events.

To stop a Run that cannot continue, cancel it explicitly: change the request’s spec (the Run fails with reason Superseded), delete the request, or delete the claim (TraceSourceDeleted). A Pending claim, such as one that waits for its first consumer, is accepted. The request starts one Run per metadata.generation, so after a Run failed, change the request’s spec to start a new Run.

# Active and recent Runs of the request
kubectl get dynamographdeploymentrequests.v1beta2.nvidia.com qwen3-trace-replay -n "$NAMESPACE" \
  -o jsonpath='{.status.activeRunRef}{"\n"}{.status.recentRunRefs}{"\n"}'
# Why a Run failed or waits
kubectl get dynamographdeploymentrun qwen3-trace-replay-1 -n "$NAMESPACE" \
  -o jsonpath='{.status.conditions}'

If the operator is uninstalled, or the v1beta2 API is disabled, while Runs are in flight, their finalizers stay on the claim and keep it from being deleted. List them, then remove only the nvidia.com/dgdr-run- finalizers (requires jq):

kubectl get pvc request-traces -n "$NAMESPACE" -o jsonpath='{.metadata.finalizers}{"\n"}'
kubectl get pvc request-traces -n "$NAMESPACE" -o json \
  | jq '.metadata.finalizers |= map(select(startswith("nvidia.com/dgdr-run-") | not))' \
  | kubectl replace -f -

Known issues

• PCIe profiler data not yet available. See the PCIe callout under SKU format.

Related pages