Rejets et modifications
Chaque rejet renvoyé par le plan de contrôle contient un code lisible par la machine, le chemin du champ qui a échoué, la valeur reçue et la forme acceptée. Branchez-vous sur le code ; ne vous basez jamais sur le texte du message, qui est rédigé pour une personne et change lorsque la formulation s’améliore.
{ "code": "healthcheck_timeout_below_floor", "field": "healthCheck.timeout", "received": "4s", "expected": ">= 10s, or omit the field", "why": "a timed-out exec is SIGKILLed and reparented to a PID 1 that never reaps it", "doc": "https://odysseus.delta-telematics.ca/docs/reference/manifest/deployment#healthcheck"}- · pkg/api/validation_response.goUn rejet signifie que rien n’a été enregistré. Corrigez le champ nommé et renvoyez-le.
Generated from Rule. Hand edits to this table are overwritten on the next build — change the Go doc comment, or the generator.
| Code | Champ | Forme acceptée | Pourquoi |
|---|---|---|---|
anchored_secret_dropped |
secrets |
conserver l’entrée {name: %q, vault_path: %q, anchor: %q}, ou supprimer le volume %q dans la même mise à jour pour libérer l’ancrage | la mise à jour supprime un secret ancré à un volume qu’elle monte toujours ; le conteneur serait recréé sans l’identifiant avec lequel son propre répertoire de données a été initialisé |
anchored_secret_repointed |
<computed> |
%q — le chemin depuis lequel le matériel du volume %q a été initialisé. Pour effectuer une rotation, utilisez POST /api/v1/deployments/{name}/secrets/rotate ; pour libérer l’ancrage, supprimez le volume %q dans la même mise à jour | modifier le chemin fait dériver le hash de la spec et recrée le conteneur, qui s’authentifie alors contre un répertoire de données inchangé avec du matériel qu’il n’a jamais vu |
deployment_name_invalid |
name |
lettres minuscules, chiffres et tirets uniquement, commençant par une lettre et se terminant par une lettre ou un chiffre — par ex. %q | le nom est utilisé tel quel comme nom de conteneur, identifiant de routeur Traefik, alias DNS sur le réseau du locataire et segment de chemin de clé Consul KV, et chacun de ceux-ci refuse les majuscules, les underscores, les points et les espaces |
deployment_name_too_long |
name |
au plus %d caractères, par ex. %q | le nom devient un label DNS pour le conteneur, et un label de plus de 63 caractères ne peut pas être résolu par les conteneurs frères |
deployment_not_found |
name, deployment_id |
le nom d’un déploiement qui existe déjà — listez-les avec GET /api/v1/deployments | une PUT met à jour un enregistrement existant et ne peut pas en créer un ; POST /api/v1/deployments crée |
dvm_recommendation_apply_invalid_spec |
spec |
une modification qui laisse le volume valide — voir le message sous-jacent | la plateforme n’écrira pas une spec de volume que son propre validateur rejette |
dvm_recommendation_bad_parameter |
parameters.<computed> |
<computed> | <computed> |
dvm_recommendation_insufficient_nodes |
parameters.target_replicas |
%d nœud(s) inscrit(s) — un pour le primaire plus un par réplique. Inscrivez-en %d de plus, ou appliquez un nombre de répliques plus petit. | chaque réplique doit se trouver sur un nœud distinct, donc N répliques nécessitent N+1 nœuds et la plateforme ne placera pas deux copies sur une seule machine |
dvm_recommendation_not_applicable |
id |
l’id d’une recommandation dont le champ « applicable » est true — lisez GET /api/v1/dvm/recommendations et agissez sur celles-ci | <computed> |
dvm_recommendation_not_found |
id |
l’id d’une recommandation retournée par GET /api/v1/dvm/recommendations pour ce locataire — relisez cette liste pour obtenir les ids actuels | les recommandations sont recalculées à partir de l’état réel du volume à chaque lecture, donc une disparaît dès que la condition qu’elle décrivait n’est plus vraie |
dvm_recommendation_stale_measurement |
parameters.target_size_bytes |
une taille d’au moins %d octets, ce que le volume contient actuellement | le volume a grossi depuis que cette recommandation a été calculée, et le redimensionner en dessous de son propre contenu sous-déclarerait les données en direct |
dvm_recommendation_tenant_required |
X-Tenant-ID |
un id de locataire, par ex. « X-Tenant-ID: acme » — les admins de la plateforme en choisissent un avec le sélecteur de locataire dans l’en-tête du tableau de bord | une recommandation concerne les volumes d’un locataire, et répondre sans locataire retournerait une liste vide qui ressemble à une vraie réponse |
dvm_recommendation_unknown_action |
parameters.action |
un parmi : %s, %s | un verbe d’action que l’endpoint d’application n’implémente pas retournerait autrefois un succès sans rien faire |
dvm_recommendation_unknown_priority |
priority |
un parmi : %s — par exemple ?priority=%s | filtrer sur une priorité qui n’existe pas retournerait une liste vide qui se lit comme une vraie réponse |
dvm_recommendation_unknown_type |
type |
un parmi : %s — par exemple ?type=%s | filtrer sur un type inexistant renverrait une liste vide qui se lirait comme une réponse réelle |
dvm_recommendation_volume_missing |
volume_id |
un volume qui existe encore dans ce locataire — lire GET /api/v1/dvm/volumes | la recommandation a été calculée à partir d’un volume qui a depuis été supprimé ou déplacé, l’appliquer écrirait donc une spec pour quelque chose qui n’existe pas |
healthcheck_command_missing |
healthCheck.command |
une commande que l’image peut exécuter, par ex. [“wget”,“-qO-”,“http://127.0.0.1:8080/health”] | une déclaration exec sans commande ne produit aucun healthcheck de conteneur |
healthcheck_retries_below_floor |
healthCheck.retries |
définissez >= %d, ou omettez retries pour utiliser la valeur par défaut de Docker | un conteneur non sain dégrade l’ensemble du déploiement, et retries est le seul amortisseur |
healthcheck_timeout_below_floor |
healthCheck.timeout |
définissez >= %s, ou omettez timeout pour utiliser la valeur par défaut de 30s de Docker | un exec ayant dépassé le délai reçoit SIGKILL et est reparenté à un PID 1 qui ne le récupère jamais |
healthcheck_type_inert |
healthCheck.type |
définissez type: “exec” avec une commande que l’image peut exécuter — forme shell [“wget -qO- http://127.0.0.1:%d%s”] ou argv [“wget”,“-qO-”,“http://127.0.0.1:%d%s”] | une déclaration inerte satisfait silencieusement les conditions de dependsOn : les portes de readiness healthy et rolling-update qu’elle était censée protéger |
healthcheck_type_unsupported |
healthCheck.type |
la seule valeur acceptée est “exec” | aucun autre type ne produit de healthcheck de conteneur |
image_not_found |
image |
une référence d’image dont le manifeste existe déjà dans le registre — poussez-la d’abord avec le tag exact que vous déployez, ou corrigez une faute de frappe dans le tag | le registre a confirmé qu’aucun manifeste n’existe pour cette référence exacte ; autoriser l’écriture détruirait le conteneur en cours d’exécution pour ensuite découvrir que l’image ne peut pas être récupérée — l’échec mesuré sur odysseus-marketing le 2026-08-21, où un conteneur sain a été arrêté deux fois pour un tag qui n’avait jamais été poussé |
image_required |
image |
une référence épinglée, par ex. “nginx:1.27” — jamais :latest | il n’y a rien à exécuter sans celui-ci |
job_node_candidates_unresolvable |
nodeId |
un nœud avec un agent joignable — inscrivez-en un ou adoptez-en un, puis réessayez | aucun nœud avec un agent joignable n’a pu être listé, donc aucune cible ne peut être honorée — soit aucun n’est inscrit, soit la passerelle n’a pas pu être lue, et les deux sont indistinguables d’ici |
job_node_not_found |
nodeId |
un parmi : %s | un job n’a pas de planificateur, donc un nœud inconnu n’est pas un placement dégradé — c’est un job qui dispatche et réessaie indéfiniment contre une machine qui n’existe pas |
manifest_wrong_kind |
kind |
kind: Déploiement — ou envoyez ce document à son propre endpoint | un Job et un Déploiement sont des primitives différentes avec des champs différents, et décoder l’un comme l’autre supprimerait les champs qu’ils ne partagent pas |
name_required |
name |
un nom en minuscules de style DNS, par ex. “web-api” | le nom est l’identité du déploiement et le préfixe du nom de son conteneur |
network_node_candidates_unresolvable |
nodeId |
inscrivez un nœud pour ce locataire, puis créez le réseau | aucun nœud n’est enregistré pour ce locataire, il n’y a donc aucun endroit où créer le réseau — soit aucun nœud n’est inscrit, soit le magasin de nœuds est injoignable, et les deux sont indistinguables depuis ici |
network_node_not_a_candidate |
nodeId |
un parmi : %s | un réseau Docker n’existe que sur l’hôte où il a été créé, et ce locataire ne peut pas placer de déploiements sur le nœud que vous avez indiqué — le réseau serait inaccessible depuis chaque conteneur que vous pourriez exécuter |
network_node_required |
nodeId |
un parmi : %s | un réseau Docker est créé sur UN SEUL hôte, donc avec plus d’un nœud disponible, la plateforme ne peut pas savoir lequel vous avez voulu — choisir pour vous est ce qui a fait apparaître des réseaux sur un nœud que personne n’attendait |
network_option_unsupported_on_agent |
<computed> |
omettez-le — ou créez le réseau directement sur le nœud jusqu’à ce que la prise en charge de l’agent soit disponible | le format de câble réseau de l’agent de nœud ne transporte que le nom, le pilote, les étiquettes et l’interne, donc cette valeur ne peut pas atteindre l’hôte et le réseau serait créé sans elle |
node_candidates_unresolvable |
nodeId |
inscrivez un nœud pour ce locataire, ou omettez nodeId pour laisser l’ordonnanceur placer ce déploiement | aucun nœud n’est enregistré sous ce locataire, donc aucune cible ne peut être honorée — soit aucun n’a été inscrit, soit le magasin de nœuds n’a pas pu être lu, et les deux sont indistinguables d’ici |
node_claim_release_no_tenant |
X-Tenant-ID |
l’UUID du locataire qui renonce à sa revendication | un nœud sous deux locataires a deux revendictions, donc une requête qui ne nomme aucun locataire ne nomme aucune revendication et pourrait supprimer l’une ou l’autre |
node_not_a_placement_candidate |
nodeId |
un parmi : %s (ou omettez nodeId pour laisser l’ordonnanceur décider) | le placement ne considère que les nœuds inscrits du locataire de ce déploiement, donc un nœud en dehors de cet ensemble serait accepté ici puis silencieusement écrasé lors de l’envoi |
node_owned_by_another_tenant |
nodeName |
un nom de nœud non déjà enregistré auprès d’un autre locataire | un nœud appartient à exactement un locataire et n’est jamais partagé. L’agent du nœud renvoie chaque conteneur sur une machine à quiconque présente un jeton pour le locataire de cette machine, car il lui fait confiance ; un second enregistrement permettrait à la charge de travail d’un locataire d’être placée sur le matériel d’un autre |
plaintext_credential_in_environment |
<computed>, environment.%s |
supprimez environment.%s et référencer Vault à la place : “secrets”: [{“name”: %q, “vault_path”: “deployments/%s”}] | Consul stocke les valeurs d’environnement en clair : elles apparaissent dans chaque export de spécification et chaque sauvegarde, et quiconque peut lire le <computed> peut lire le secret |
query_parameter_unknown |
<computed> |
<computed> | <computed> |
registry_credential_store_unavailable |
image |
rien — votre requête est bien formée. Réessayez une fois que le plan de contrôle signale un état sain ; un opérateur doit vérifier que ODYSSEUS_CONSUL_ADDRESS est défini et que /healthz indique consul connected | le plan de contrôle n’a pas pu atteindre son propre magasin d’identifiants, il ne peut donc pas déterminer si cette image est téléchargeable, et il n’acceptera pas une écriture qu’il ne peut pas vérifier lorsque la raison est sa propre faute plutôt que celle du registre — un registre qui est simplement inaccessible est autorisé avec un avertissement |
replicas_negative |
replicas |
0 ou supérieur — utilisez 0 pour arrêter le déploiement sans le supprimer | un nombre de réplicas négatif n’a pas de sens ; mettre à 0 est la façon d’arrêter quelque chose |
replicas_out_of_range |
replicas |
un entier entre 0 et %d (max_replicas_per_deployment ; augmentez-le dans la configuration du plan de contrôle si votre cluster exécute réellement plus) | un nombre de répliques incontrôlé épuise chaque nœud de la flotte avant qu’un quota puisse l’arrêter ; la mise à l’échelle zéro (0) est autorisée, les négatifs n’ont pas de sens |
reserved_infrastructure_name |
name |
tout nom autre que %q — celui-ci est réservé à l’échelle de la plateforme car le plan de contrôle s’y connecte en tant que %s (configuré dans %s). Si vous souhaitiez modifier la base de données de la plateforme elle-même, éditez infrastructure/docker-compose.yml sur le nœud ; il s’agit délibérément d’un déploiement Odysseus. Si vous souhaitez une base de données propre, %q ou %q sont disponibles. | %s est un service dont le plan de contrôle a besoin pour enregistrer ses actions, il ne peut donc pas être un déploiement que le plan de contrôle lance — lors d’un démarrage à froid, le plan de contrôle attendrait un conteneur qu’il n’a pas encore démarré, et la piste d’audit de ce démarrage serait perdue |
rotation_transition_invalid |
phase |
un parmi %v de la phase %q | la fenêtre de chevauchement garantit qu’à aucun moment zéro identifiants ne sont valides, et cette garantie ne tient que si les phases avancent dans l’ordre |
secret_anchor_invalid |
<computed> |
un parmi : “process”, “external”, ou “volume(<volume-id>)” — par ex. “volume(codecheck-db-data)” | l’ancre indique à la plateforme si cet identifiant peut être régénéré ; une valeur non reconnue serait silencieusement ignorée, ce qui est la défaillance que ce champ existe pour prévenir |
secret_anchor_volume_ephemeral |
<computed> |
un volume de type “volume” ou “bind” ; %q est de type %q. Utilisez “process” si le matériel est véritablement recréé avec le conteneur | tmpfs est éphémère par définition — il est jeté avec le conteneur, il n’ancrerait rien et une ancre sur lui accorderait une fausse garantie |
secret_anchor_volume_not_declared |
<computed> |
volume(<id>) nommant un volume que cette spécification déclare ; déclaré ici : %v | une ancre pointant vers un volume que le déploiement ne monte pas ne protège rien — le matériel serait régénéré lors de la prochaine recréation et le conteneur s’authentifierait avec un identifiant que son magasin de données n’a pas |
secret_compose_no_reference |
<computed> |
un modèle contenant au moins un {{secret.<resource>.<key>}} | un modèle sans référence de secret est une constante et appartient à environment:, où il est visible et comparable |
secret_compose_resource_undeclared |
<computed> |
une ressource que ce déploiement déclare : %v | un modèle ne peut lire qu’une ressource que le déploiement référence déjà, donc une faute de frappe est détectée ici au lieu d’échouer à l’envoi sans conteneur |
secret_compose_template_empty |
<computed> |
postgresql://user:{{secret.<resource>.<key>}}@host:5432/db | un modèle vide se rend comme une variable d’environnement vide, que le consommateur lit comme non définie |
secret_compose_template_malformed |
<computed> |
{{secret.<resource>.<key>}} — ressource DNS en minuscules, clé au format variable d’environnement | un placeholder non reconnu serait remis au conteneur sous forme d’accolades littérales, et le déploiement se connecterait avec le mauvais identifiant |
secret_generate_axis_conflict |
generate |
soit octets/encodage (octets aléatoires rendus sous forme de texte) OU longueur/jeu de caractères (caractères tirés d’un alphabet) — pas les deux | les deux décrivent des choses différentes et la plateforme devrait ignorer l’un des deux, ce qu’elle ne fera pas silencieusement |
secret_generate_below_entropy_floor |
generate.length |
longueur >= %d avec le jeu de caractères %q (ou omettre la longueur pour la valeur par défaut %d) | une longueur de %d sur un alphabet de %d caractères donne %.0f bits ; le plancher de la plateforme est de %d bits, en dessous duquel la force brute hors ligne est une question de budget plutôt que de physique |
secret_generate_bytes_out_of_range |
generate.bytes |
%d..%d (omettre pour la valeur par défaut %d) | %d octets font %d bits ; le plancher de la plateforme est de %d bits, et au-delà de %d octets la valeur encodée dépasse le plafond de %d caractères pour lequel Vault est dimensionné |
secret_generate_charset_unknown |
generate.charset |
un parmi %q, %q, %q | un alphabet inconnu ne peut pas être vérifié en termes d’entropie, donc la plateforme ne peut pas garantir que la valeur atteint son plancher |
secret_generate_encoding_unknown |
generate.encoding |
un parmi %q, %q, %q | la plateforme ne peut pas rendre des octets dans un encodage qu’elle n’implémente pas, et en deviner un fournirait à votre application du matériel qu’elle ne peut pas décoder |
secret_generate_key_duplicate |
<computed> |
chaque clé listée une fois | un doublon serait créé deux fois et la seconde écriture l’emporterait silencieusement |
secret_generate_keys_required |
generate.keys |
au moins une clé, par ex. [“password”] | un bloc generate sans clés ne crée rien et produit silencieusement une référence vers un document vide, qui échoue de manière sécurisée lors de la distribution |
secret_generate_length_out_of_range |
generate.length |
1..%d | une longueur négative n’a pas de sens et une longueur excessive serait refusée par Vault après une écriture partielle |
secret_generate_would_persist |
secrets[%d].generate |
nil — appeler StripSecretAuthoring avant la persistance | un bloc generate stocké serait réévalué à chaque rollback et pourrait créer du matériel qu’un magasin de données ne connaît pas |
secret_key_invalid |
<computed> |
un nom de variable d’environnement correspondant à [A-Za-z_][A-Za-z0-9_]*, par ex. « S3_ACCESS_KEY » | la clé du document devient la variable d’environnement du conteneur telle quelle, et un chiffre en tête n’est pas assignable dans sh |
secret_key_provided_and_generated |
<computed> |
déclarez la clé dans values OU dans generate.keys, pas les deux | la plateforme devrait choisir entre votre valeur et une valeur générée, et l’un ou l’autre choix constitue une modification silencieuse |
secret_material_would_persist |
secrets[%d].values |
une map values vide — appelez StripSecretAuthoring avant la persistance | Consul KV ne contient que des références ; une valeur stockée entrerait dans le hash de la spec, à chaque révision et à chaque rollback |
secret_mount_path_unsupported |
secrets[%d].mount_path |
supprimez mount_path ; générez le fichier au démarrage du conteneur à partir de la valeur d’environnement avec un entrypoint | la livraison est uniquement par variable d’environnement (décision WP2 D1) — un montage de fichier placerait la valeur sur un disque que le plan de contrôle ne contrôle pas |
secret_name_invalid |
secrets[%d].name |
un préfixe de variable d’environnement : [A-Za-z0-9_]+, par ex. « DB_CREDS » | le nom est préfixé à chaque clé résolue à partir de ce document (NAME_key), il doit donc être lui-même un nom de variable d’environnement valide |
secret_path_name |
<computed> |
un label DNS après l’espace de noms : lettres minuscules, chiffres et tiretes internes, 1 à 63 caractères, par ex. « resources/codecheck-db » | le nom est comparé aux noms des déploiements pour détecter un identifiant référencé sous deux espaces de noms à la fois ; un chemin qui ne nomme aucun document ne peut pas participer à cette comparaison et ne se résout en rien lors du dispatch |
secret_path_namespace |
<computed>, namespace |
<computed> | seuls ces espaces de noms sont accordés par la politique Vault du plan de contrôle et par les politiques d’application des locataires ; tout le reste se résout en 403 lors du dispatch et le déploiement passe en Degraded sans conteneur |
secret_path_namespace_split |
secrets[%d].vault_path |
un espace de noms par identifiant — utilisez %q pour chaque référence à %q | le même identifiant sous deux espaces de noms correspond à deux documents Vault qui doivent être maintenus identiques à la main ; cette duplication est ce que l’espace de noms resources/ existe pour supprimer |
secret_path_shape |
<computed>, resource |
<computed> | le premier segment est l’espace de noms contre lequel est écrite chaque attribution de politique Vault — celle du plan de contrôle et celle de chaque application locataire ; un chemin en dehors d’un espace de noms accordé se résout en 403, et un 403 est indistinguable d’un secret vide pour un appelant qui ne le classe pas |
secret_rotation_unsupported |
secrets[%d].rotation |
“restart”, ou omettez le champ — la valeur par défaut est restart | le conteneur n’acquiert le nouveau matériau qu’en étant recréé ; signal/webhook/file_watch n’ont jamais été implémentés et ne feraient rien silencieusement |
secret_value_empty |
<computed> |
une chaîne non vide | une valeur vide se résout en une variable d’environnement vide, que la plupart des images traitent comme non définie et qui échoue ensuite de manière obscure à l’exécution |
secret_value_too_long |
<computed> |
au plus %d octets | Vault KV v2 plafonne un document et une valeur surdimensionnée serait rejetée au moment de l’écriture, après que d’autres clés aient déjà été stockées |
secret_vault_path_not_relative |
secrets[%d].vault_path |
un chemin relatif sans “/” initial et sans éléments “..”, par ex. “deployments/codecheck-db” | le chemin est ajouté à l’espace de noms Vault propre au locataire ; une barre oblique initiale ou “..” l’en ferait sortir et atteindrait le matériau d’un autre locataire |
secret_vault_path_required |
secrets[%d].vault_path |
un chemin KV Vault relatif à l’intérieur du montage du locataire, par ex. “deployments/codecheck-db” | sans cela, le plan de contrôle n’a rien à résoudre lors de la distribution et le déploiement échoue en mode fermé sans conteneur |
secret_write_empty |
values |
soit {“values”:{“KEY”:“…”}} soit {“generate”:{“keys”:[“KEY”]}} | une écriture sans aucun des deux ne fournit rien et créerait un document vide qui échoue en mode fermé lors de la distribution |
secrets_version_negative |
secretsVersion |
0 sur une nouvelle spécification ; ensuite seul l’API de rotation l’incrémente | secretsVersion est le compteur de rotation couvert par le hash de la spécification — une valeur négative ne peut pas avoir été produite par une rotation, donc la spécification ne provient pas de cette plateforme |
volume_access_mode_conflict |
<computed> |
exactement un consommateur en lecture-écriture par volume répliqué/éphémère (ReadWriteOnce) — montez en lecture seule, ou détachez d’abord l’autre déploiement | deux rédacteurs concurrents sur un volume à rédacteur unique se corrompent mutuellement ; le rédacteur unique est la garantie de la classe |
volume_binding_unavailable |
volumes |
supprimez les montages distribués, ou activez la gestion des volumes sur ce plan de contrôle | admettre le montage sans contrôleur stockerait un lien que rien ne peut résoudre |
volume_class_not_wired |
<computed> |
une volume de classe « éphémère » ou « répliquée » | la classe de stockage %q n’est pas encore dispatchable — son câblage backend est la tranche suivante du jalon 28, et la lier maintenant monterait silencieusement un stockage local au nœud au lieu de ce que la classe promet |
volume_mount_shape |
volumes[%d].%s |
<computed> | <computed> |
volume_not_found |
<computed> |
l’ID typé d’un volume que ce locataire possède — listez-les avec GET /api/v1/dvm/volumes | la référence ne résout pas un volume appartenant à ce locataire |
volume_not_ready |
<computed> |
un volume en phase « Ready » | monter un volume qui est encore en cours de matérialisation (ou dégradé) dispatche un conteneur contre un stockage qui peut ne pas exister sur le nœud cible encore |
volume_primary_mismatch |
nodeId |
%q (le primaire actuel du volume), ou omettez nodeId et laissez le placement suivre le volume | un montage en lecture-écriture hors du nœud primaire écrirait sur une réplique, que la passe de réplication suivante écrase alors — perte de données, pas une préférence |
volume_snapshot_not_found |
snapshots/{snap} |
l’id d’un enregistrement de snapshot que ce volume détient réellement — listez-les avec GET /api/v1/tenants/{tenant}/volumes/{id}/snapshots. Cette liste est normalement vide : la création de snapshot est refusée avec volume_snapshot_not_implemented, donc les seuls enregistrements qui peuvent exister sont ceux écrits avant que ce refus soit déployé | un id distribué par l’ancien endpoint nommé un travail jamais démarré, donc un 404 ici n’est généralement pas un enregistrement égaré mais volume_snapshot_not_implemented apparaissant un appel plus tard |
volume_snapshot_not_implemented |
<computed> |
il n’existe pas de forme acceptée de cette requête : l’opération n’a pas d’implémentation derrière elle, donc aucun corps ne réussirait. Ce qu’Odysseus offre, et le besoin que chacun comble — (1) pour garder les DONNÉES d’un volume disponibles lorsque le nœud qui le détient est perdu, donnez des réplicas au volume : POST /api/v1/tenants/{tenant}/volumes/{id}/replicas {“node_id”:“<node>”} sur un volume de classe « replicated », qui maintient une copie active sur un autre nœud et la promeut lorsque le primaire disparaît ; (2) pour garder une copie à un instant donné de la CONFIGURATION d’un déploiement — sa spécification, sa politique de mise à l’échelle, son état canary et son historique de révisions — utilisez Backups pour un retour en arrière rapide après un changement risqué (POST /api/v1/backups {“deploymentName”:“<name>”}) ou Archives pour un historique versionné permettant de remonter plus loin dans le temps (GET /api/v1/archives/deployments/{name}) ; ni l’un ni l’autre ne lit ou n’écrit un seul octet sur un volume ; (3) pour garder une copie à un instant donné des OCTETS d’un volume, prenez-la depuis l’intérieur du workload qui les possède — un déploiement de cronjob planifié qui monte le volume et écrit son dump hors du nœud, par exemple vers un volume de classe « object » — car seul ce workload sait quand ses données sont cohérentes | rien dans la plateforme ne prend de snapshot de volume distribué — aucun agent de nœud n’expose une opération de snapshot et aucun contrôleur ne consomme une requête de snapshot — donc accepter cela remettrait un identifiant pour un travail qui ne démarre jamais, ne se termine jamais et ne peut jamais être récupéré |
Altérations — modifications effectuées par le serveur que vous n’avez pas envoyées
Section intitulée « Altérations — modifications effectuées par le serveur que vous n’avez pas envoyées »Une altération silencieuse est un rejet silencieux déguisé en 200. Chaque entrée ci-dessous est annoncée dans le corps de la réponse et dans le journal, donc un changement de votre déploiement n’est jamais quelque chose que vous devez découvrir.
Generated from Rule. Hand edits to this table are overwritten on the next build — change the Go doc comment, or the generator.