Service de gestion DOCA (DMS)

⚠️ Opérations destructrices. Les opérations gNOI reboot, OS install et factory-reset sont irréversibles et impactantes pour le service — elles peuvent mettre hors ligne une BlueField ou ConnectX de production ou effacer sa configuration. Avant de lancer l'une d'elles, l'agent DOIT : (1) vérifier l'identité du périphérique cible, et (2) obtenir une confirmation explicite de l'utilisateur pour cette action destructrice spécifique. Ne les invoquez jamais de manière spéculative ou comme effet secondaire d'une autre tâche. Consultez le guide public DMS pour les recommandations de sécurité relatives à ces opérations.

Par où commencer : Cette skill concerne l'exploitation de DMS, non le lien contre une bibliothèque. Si l'utilisateur souhaite déployer ou lancer le daemon, ouvrez TASKS.md et commencez à ## configure. Si la question porte sur la nature du service DMS et les protocoles qu'il utilise, commencez à CAPABILITIES.md. Si DOCA n'est pas encore installé sur le point de gestion, routez d'abord vers doca-setup.

Exemples de questions auxquelles cette skill répond bien

Les CLASSES de questions DMS que cette skill est construite pour répondre, chacune avec un exemple travaillé. La classe est l'élément porteur ; l'exemple travaillé est une instance.

« Où DMS doit-il fonctionner pour ma topologie cible ? » — exemple travaillé : « J'ai un hôte sans DPU ; puis-je quand même gérer une ConnectX distante ? ». Réponse par la décision de forme de déploiement dans CAPABILITIES.md ## Capabilities and modes
- TASKS.md ## configure.
« Quel mode d'authentification dois-je choisir pour ma posture de sécurité ? » — exemple travaillé : « un environnement multi-locataire de production vs un lab mono-locataire ». Réponse par le tableau des compromis du mode d'authentification dans CAPABILITIES.md ## Safety policy
- l'étape de câblage d'authentification dans TASKS.md ## configure.
« Comment lancer une requête gNMI Get / Set contre un chemin modelé ? » — exemple travaillé : « définir /interfaces/interface/config/mtu sur une interface distante ». Réponse par la surface gNMI/gNOI dans CAPABILITIES.md ## Capabilities and modes
- le workflow de forme de requête dans TASKS.md ## run.
« Comment exécuter une opération gNOI (reboot, OS install, transfert de fichier) ? » — exemple travaillé : « déclencher un redémarrage propre de la cible via gNOI ». Réponse par le catalogue gNOI dans CAPABILITIES.md ## Capabilities and modes
- le workflow run dans TASKS.md ## run.
« Ma requête DMS a retourné une erreur — était-ce le frontend ou le backend ? » — exemple travaillé : « mlxconfig a échoué sous DMS mais fonctionne sur le shell ». Réponse par la séparation frontend-vs-backend dans CAPABILITIES.md ## Error taxonomy
- l'échelle en couches dans TASKS.md ## debug.
« Où puis-je lire les logs DMS et comment les faire pivoter ? » — exemple travaillé : « répertoire de log persistant + journald + politique de rotation des logs ». Réponse par la surface de journalisation dans CAPABILITIES.md ## Observability
- l'étape de rotation des logs dans TASKS.md ## configure.

Audience

Cette skill sert les opérateurs externes et les équipes de plateforme qui déploient et exploitent DMS pour gérer les plates-formes de réseau NVIDIA® BlueField® ou les SmartNICs NVIDIA® ConnectX® à partir d'un plan de contrôle centralisé. Concrètement : les personnes exécutant dmsd, intégrant des clients gNMI/gNOI contre lui, choisissant un mode d'authentification, ou câblant DMS dans un déploiement Kubernetes.

Elle n'est pas pour les développeurs NVIDIA contribuant à DMS lui-même, et elle n'est pas un guide de programmation pour construire des applications sur les bibliothèques DOCA (cela relève de doca-programming-guide plus la skill correspondante de la bibliothèque sous libs/). DMS est un service, pas une bibliothèque : l'utilisateur l'invoque comme un daemon et communique avec lui via gRPC ; il ne crée pas de lien contre libdms.so pour écrire son propre programme.

Note de statut. D'après le guide public DMS, DMS est actuellement en bêta, avec une disponibilité générale délimitée aux cas d'usage SPC-X. La skill reflète la posture du guide public : prescrire les chemins de lancement / authentification / déploiement documentés, suivre les bonnes pratiques de sécurité documentées, et reporter les questions de feuille de route et de portée GA au guide public actif plutôt que de spéculer.

Quand charger cette skill

Chargez cette skill quand l'utilisateur fait du travail d'exploitation DMS pratique contre une cible BlueField ou ConnectX où DOCA est déjà installé sur le point de gestion (hôte, DPU ou pod). Concrètement :

Décider où DMS doit fonctionner (hôte non-DPU / BlueField Arm / pod Kubernetes) pour une topologie cible donnée.
Mettre en place le daemon dmsd — choisir SystemD vs lancement manuel, sélectionner un mode d'authentification, câbler -allowed_users (la limite d'autorisation du client gRPC) et, si nécessaire, dmsgroup (le groupe Unix dmspe du helper backend).
Lancer des requêtes gNMI Get / Set contre des chemins modelés (par ex. /interfaces/interface/config/mtu).
Lancer des opérations gNOI : OS install, reboot, transfert de fichier, factory-reset, mlxconfig, containerz.
Choisir un mode d'authentification (localhost / PAM / credentials / mTLS) et comprendre les compromis de sécurité que le guide public signale.
Lire ou faire pivoter les logs DMS, configurer la persistance de la configuration, ou récupérer après une panne du daemon.
Déboguer une requête DMS qui a retourné une erreur — séparer « le frontend a rejeté avant d'atteindre le backend » de « le backend a exécuté et l'outil sous-jacent (par ex. mlxconfig) a échoué ».

Ne chargez pas cette skill pour l'orientation générale DOCA, l'installation de DOCA lui-même, ou les questions d'API de bibliothèque. Pour celles-ci, routez via doca-public-knowledge-map, doca-setup, ou la skill correspondante libs/<library>.

Ce que cette skill fournit

C'est un chargeur allégé. Le matériel substantiel vit dans deux fichiers complémentaires :

CAPABILITIES.md — architecture DMS (frontend dmsd / backend dmspe privilégié), protocoles de gestion (gNMI, gNOI), le dictionnaire de configuration unifié basé sur YANG, les formes de déploiement, les modes d'authentification avec leurs compromis de sécurité, le modèle de persistance de la configuration, la surface de journalisation, et la posture de sécurité documentée de DMS.
TASKS.md — workflows étape par étape pour les verbes DMS in-scope : configure, build, modify, run, test, debug, plus un bloc Deferred task verbs routant les questions hors périmètre.

La skill suppose un hôte où DOCA est déjà installé et que l'opérateur a accès root / sudo où le guide public dit que c'est requis. Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup.

Ce que cette skill n'embarque délibérément pas

Cette skill est une orientation pour agent, pas un bundle de templates ou de configurations d'exemple. Pour garder la limite claire, elle ne contient délibérément pas — et les pull requests ne doivent pas ajouter :

Des fichiers de configuration DMS précuits (documents d'instance YANG, configurations d'exemple full-stack, bundles de flags dmsd prêts à lancer) destinés à être copiés-collés en production. Les configurations sont spécifiques au déploiement et la réponse sûre pour un opérateur externe est de les dériver du guide public par rapport à sa propre cible. Le travail de l'agent est de prescrire la procédure et de citer les flags et chemins documentés, non de fournir une configuration que l'utilisateur pourrait lancer sans modification.
Des programmes clients gNMI / gNOI pré-écrits dans un quelconque langage. La surface client est gNMI / gNOI standard (documentée publiquement) ; la skill décrit quels chemins et opérations DMS supporte, non comment construire un client gRPC en langage X.
Du matériel TLS, des credentials, ou des stanzas PAM. Ce sont des artefacts spécifiques à l'environnement utilisateur ; la skill pointe vers les commandes de configuration documentées et les bonnes pratiques de sécurité documentées et s'arrête là.
Un sous-arbre samples/, templates/ ou reference/ d'aucune sorte. Un artefact simulé ou incomplet dans l'arbre de cette skill, même s'il est étiqueté « reference », est trompeur : les opérateurs le liront comme prêt pour la production.

Ordre de chargement

Lisez ce SKILL.md d'abord pour confirmer que la question de l'utilisateur est in-scope.
Pour l'architecture DMS, les formes de déploiement, les modes d'authentification, l'inventaire de protocoles/chemins, la persistance, la journalisation et la posture de sécurité, voir CAPABILITIES.md.
Pour les workflows étape par étape — configure, build, modify, run, test, debug — voir TASKS.md.

Skills connexes

doca-public-knowledge-map — la table de routage vers le guide public DMS et le reste de l'ensemble de documentation DOCA publique.
doca-setup — préparation d'environnement et vérification d'installation sur l'hôte où dmsd s'exécutera, incluant le chemin je n'ai pas encore d'installation via le conteneur DOCA NGC public. Cette skill suppose que ses préconditions sont satisfaites au point de gestion.
doca-programming-guide — motifs DOCA généraux. DMS a une forme de service non de bibliothèque, donc le motif build / modify / first-app là ne s'applique pas directement, mais la taxonomie DOCA_ERROR_* entre bibliothèques et l'ordre de débogage en couches restent utiles quand DMS signale des erreurs originaires d'une bibliothèque DOCA qu'il a appelée.

doca-dms