DOCA Management Service Operations
Operate and troubleshoot NVIDIA DMS for centralized BlueField and ConnectX management.
The files explicitly require target verification and per-action confirmation for reboot, OS install, and factory reset, and describe a low-privilege dmsd frontend, privileged dmspe backend, allowed_users authorization, and authentication choices. The main safety boundaries are therefore visible. Points are deducted for no explicit rollback or recovery plan, less complete confirmation guidance for file deletion, and license ambiguity between the NOASSERTION metadata and file-level declarations.
SKILL.md, CAPABILITIES.md, and TASKS.md are broadly consistent and cover deployment, authentication, testing, and layered diagnosis, while requiring installed-binary and live-guide verification for flags and paths. Static files provide no independently reproducible committed test suite or real CI coverage, and many critical details are delegated to an external guide, so the score remains below the static ceiling.
The audience, BlueField/ConnectX deployment shapes, trigger phrases, protocol scope, and non-fit cases are clearly stated; authentication, Kubernetes, and telemetry boundaries are also described. Points are deducted because core use depends on live overseas documentation and NVIDIA environments, with no mainland-China reachability, offline alternative, or Chinese-language support evidence.
The documentation is well layered and supplies loading order, task workflows, a command appendix, related skills, limitations, and security intake. The skill card also names an owner, issue paths, and version fields. Points are deducted because the version, signature, and scan identifiers remain TBD, maintenance and changelog evidence is incomplete, and Apache-2.0, CC-BY-4.0, and NOASSERTION metadata are ambiguous.
The skill provides directly usable guidance for DMS operations, authentication selection, gNMI/gNOI scope decisions, and fault-layer separation, while explicitly avoiding invented flags and paths. Points are deducted because it is a thin loader dependent on the live public guide and ships no executable configuration, client, or complete examples; the benchmark claims a pass but its dataset is unavailable, so broad effectiveness is not statically established.
The files provide task definitions, an evaluation report, metrics, and some source-symbol/path references, offering limited auditability. Points are deducted because the evaluation dataset is unavailable, no verifiable CI and committed test suite are supplied, public documentation lacks pinned links, and several capability claims remain author assertions.
- Reboot, OS install, factory reset, and file deletion can cause outages or data loss; confirm the exact target, sub-operation, and impact before execution, and note that a complete rollback plan is not supplied.
- Flags, YANG paths, authentication semantics, and operation lists depend on a live public guide matching the installed DOCA version; do not execute production changes from this static text alone.
- The evaluation report's source dataset is unavailable, so its results are not independently reproducible evidence for this review.
- Stable reachability of the public NVIDIA documentation from mainland-China networks is not demonstrated, and no offline documentation or Chinese-support path is provided.
- License information is ambiguous: the prompt metadata says NOASSERTION, while files declare Apache-2.0 or Apache-2.0 AND CC-BY-4.0.
What does this skill do, and when should you use it?
This skill helps external operators run NVIDIA DOCA Management Service on a Linux management endpoint where DOCA is already installed. It covers deployment shapes for x86 hosts, BlueField Arm systems, and Kubernetes pods, along with authentication, gNMI/gNOI operations, logging, persistence, and troubleshooting. DMS exposes gRPC management through the dmsd frontend and privileged dmspe backend helper. Destructive operations such as reboot, OS installation, factory reset, and managed-file deletion require target-bound explicit confirmation.
Guides operation of dmsd and dmspe on an x86 host, BlueField Arm host, or Kubernetes pod; helps choose SystemD or manual launch, configure -allowed_users and dmsgroup, and select localhost, PAM, credentials, or mTLS authentication. It structures gNMI Get, Set, and Subscribe requests against modeled paths and supported gNOI workflows. It also helps inspect or rotate logs, reason about configuration persistence and daemon crashes, and separate frontend rejection from backend or underlying-tool failures. It does not ship production-ready configuration files, credentials, TLS material, or client programs.
- A platform team needs to manage a remote BlueField or ConnectX from a centralized control plane and must choose where DMS should run.
- An operator must choose an authentication mode for a multi-tenant production environment or a single-tenant lab.
- A network engineer needs to issue gNMI Get, Set, or Subscribe requests, such as changing an interface MTU on a modeled path.
- An authorized operator needs to perform a gNOI reboot, OS installation, file transfer, factory reset, or mlxconfig workflow.
- A DMS request fails and the team needs to determine whether the frontend rejected it or a backend tool failed.
What are this skill's strengths and limitations?
- Covers x86 host, BlueField Arm, and Kubernetes-pod deployment shapes.
- Includes gNMI, gNOI, authentication, logging, persistence, and layered troubleshooting guidance.
- Defines an explicit target-bound confirmation gate for destructive operations.
- Clearly separates DMS operations from DOCA installation and library/API development.
- Requires DOCA to be installed on the management endpoint and generally assumes root or sudo access.
- Does not provide production-ready configuration files, TLS material, credentials, or client programs.
- Users must verify that the public DMS guide matches the installed DOCA release; the source does not provide a complete version-specific command reference.
- The source describes DMS as beta, with General Availability scoped to SPC-X use cases.
How do you install this skill?
The repository README supports installing one skill with the skills CLI: npx skills add nvidia/skills --skill doca-dms --yes. You can also run npx skills add nvidia/skills and select the skill and destination interactively. The skill becomes available when the agent next loads relevant skills. The source does not document additional manual installation steps.
How do you use this skill?
Confirm that DOCA is installed on the Linux management endpoint and that the request concerns DMS operation rather than DOCA installation or library/API development. Example prompt: “Configure DMS on a Linux host with DOCA installed to manage a remote BlueField, and recommend an authentication mode.” For architecture, protocol, logging, and workflow details, use the companion CAPABILITIES.md and TASKS.md files. Before any reboot, OS installation, factory reset, or managed-file deletion, verify the exact target identity and obtain explicit confirmation bound to that target and action.
How does this skill compare with similar options?
Unlike doca-setup, this skill does not install DOCA; it operates DMS after the prerequisite installation is present. Unlike doca-programming-guide and library skills, it addresses service operation and gRPC management interfaces rather than building applications against DOCA libraries. For turnkey aggregation, the source routes users to the externally productized DOCA Telemetry Service.