DOCA Container Deployment
Deploy, validate, and troubleshoot DOCA service containers on NVIDIA BlueField.
The documents require authoritative-guide lookup, prohibit inventing images or fields, and define smoke-before-bulk, rollback baselines, out-of-band access, and layered diagnosis. They do not establish concrete least-privilege rules, user-confirmation gates, or safety constraints for high-impact settings such as privileged access or host networking, and they depend on external NGC pulls; 8 points are deducted.
Loading order, preconditions, three-layer observation, and the eight-layer fault taxonomy are generally coherent, with explicit guidance to diagnose before restarting. However, key commands, paths, and fields are delegated to external guides, service coverage is inconsistent across files, and static review cannot reproduce key paths; 12 points are deducted, yielding 8 within the static ceiling.
The audience, trigger examples, container-versus-bare-metal boundary, and non-goals are clearly stated. Chinese-language guidance is absent, no mainland-China fallback is described for potentially restricted NGC or documentation access, and built workloads still require additional routing; 6 points are deducted.
The material has layered information architecture, cross-references, workflows, and limitation disclosures, and NVIDIA ownership plus repository synchronization are indicated. However, metadata says NOASSERTION while the skill card states Apache 2.0 AND CC-BY-4.0, author metadata is missing, version/change governance is incomplete, and the benchmark reports missing Instructions/Examples; 7 points are deducted.
The skill supplies deployment decisions, precondition checks, smoke validation, and layered troubleshooting that can reduce generic Kubernetes misguidance. It is nevertheless a thin loader without executable commands, concrete paths, pod specs, or representative complete outputs; core completion depends on omitted external guides and other skills. 9 points are deducted, yielding 6 within the static ceiling.
There is substantial internal traceability among the supplied files and a benchmark report. The benchmark dataset is unavailable, no committed coverage tests or third-party execution evidence are supplied, and the referenced external-guide content is absent from the evidence; 6 points are deducted, yielding 4 within the static ceiling.
- Do not generate or execute pod specs, images, paths, kubelet flags, or privileged settings from this skill alone; verify them against the official guide for the target BFB/DOCA version.
- Before production deployment on a BlueField, establish explicit user confirmation, least privilege, the impact of hostNetwork/privileged access and mounts, a maintenance window, and a recoverable previous configuration.
- NGC and official documentation may be network- or region-constrained; the supplied material provides no mainland-China reachability or offline-image plan.
- Resolve the license inconsistency and add author, version, changelog, examples, and reproducible tests.
What does this skill do, and when should you use it?
This skill supports external operators and platform teams deploying Argus, DMS, Firefly, or UROM service containers on BlueField. It covers the shared runtime pattern: standalone kubelet on the BlueField Arm watches a static-pod manifests directory and schedules containers from dropped YAML pod specs. Workflows span configure, build, modify, run, test, and debug, with smoke validation required before bulk workload. It excludes DOCA installation, service-specific configuration schemas, library APIs, and full Kubernetes cluster operations.
Guides operators to drop YAML pod specs into the documented static-pod manifests directory; inspect kubelet pod status, container logs, ENTRYPOINT logs, and service-side liveness; classify failures across pod-spec, scheduling, image-pull, runtime, mount, network, version, and host layers; verify that a pod reaches Running, produces clean ENTRYPOINT logs, and answers a basic liveness probe before broader deployment; and route restart loops, missing mounts, network-policy blocks, and host-firewall issues to the appropriate diagnostic layer.
- A platform team has DOCA installed on the BlueField Arm and needs to deploy an Argus, DMS, Firefly, or UROM service container.
- An operator has dropped a pod YAML file but the pod remains Pending and needs cross-cutting scheduling diagnosis.
- A container is Running while the service inside is not ready, requiring log and liveness validation.
- A deployment encounters ImagePullBackOff, CrashLoopBackOff, missing volume mounts, or network blocking.
- A team needs to run multiple supported DOCA services on one BlueField and validate them before workload expansion.
What are this skill's strengths and limitations?
- Covers the shared deployment runtime for four supported DOCA services.
- Provides a layered observability model from pod status through service readiness.
- Includes an explicit smoke-before-bulk safety policy and eight-layer error taxonomy.
- Clearly separates container deployment from DOCA setup, service-specific configuration, and full Kubernetes operations.
- It is not a general Kubernetes tutorial and does not cover a Kubernetes control plane.
- It does not install DOCA or document service-specific configuration schemas.
- It deliberately avoids re-documenting kubelet flags, pod-spec field names, and image tags; those details depend on companion documentation.
- Validation assumes an existing DOCA installation, standalone kubelet, container runtime, host permissions, and image-pull connectivity.
How do you install this skill?
Install the individual skill with the NVIDIA skills CLI:
npx skills add nvidia/skills --skill doca-container-deployment --yes
The README states that the npx-based CLI prompts for the installation destination; cloning the repository or manually copying skill folders is not required.
How do you use this skill?
Ask an agent with the skill loaded a concrete deployment question such as "How do I run my built service on the BlueField?", "My pod is stuck in ImagePullBackOff", or "Can I have DMS and Firefly on the same BlueField?" If the container-versus-bare-metal decision has not been made, route first through doca-setup's recognize workflow. Once on the container path, read TASKS.md and consult CAPABILITIES.md for the runtime contract and safety policy.
How does this skill compare with similar options?
Compared with doca-bare-metal-deployment, this skill targets packaged DOCA service containers managed by standalone kubelet, while the sibling skill targets directly launched DOCA-linked application binaries. Compared with full Kubernetes operations, it covers only the BlueField standalone-kubelet pattern without a cluster control plane.