Ce que Feint prouve, et ce qu'il ne prouve pas

Un émulateur qui laisserait croire à ce qu'il ne vérifie pas serait pire qu'inutile. Cette page répond à une seule question, avant que vous n'installiez quoi que ce soit : que puis-je raisonnablement tester contre Feint ? En résumé, le contrat d'API, le cycle de vie Terraform et le comportement de votre client sont testables ; les prix, les quotas, la capacité réelle et les permissions IAM ne le sont pas.

Ce que vous allez obtenir

À la fin de cette page, vous saurez décider si un test donné a un sens ici, dire ce qui établit chaque verdict plutôt que de vous fier à une promesse, et reconnaître la limite qui peut coûter de l'argent.

• Lire la matrice ligne par ligne, dans votre vocabulaire.
• Distinguer un « oui » d'un « oui, avec un runtime ».
• Identifier la limite la plus dangereuse, celle qui laisse fuir du trafic.
• Comprendre pourquoi aucun pourcentage de couverture n'est publié.

La matrice des verdicts

Chaque ligne porte son verdict et ce qui l'établit. Un « non » n'est pas un trou en attente de comblement : c'est une décision assumée, avec une raison écrite et une date.

Deux mots reviennent dans la colonne de droite. Un runtime est le logiciel qui fait tourner de vraies machines sous Feint : Incus, installé sur votre hôte (voir la page d'installation). OVN (Open Virtual Network) est le réseau virtuel qu'Incus peut utiliser pour isoler des réseaux les uns des autres ; sans lui, certaines vérifications de réseau n'ont pas de sens.

Ce que vous voulez valider	Verdict	Ce qui l'établit, ou la limite
Syntaxe, plan et cycle de vie Terraform ou OpenTofu	oui	la suite de conformité : apply, second plan vide, destroy
Un parcours complet avec scw, octl ou exo	oui, sauf CreateKeypair avec octl	la même exécution pilote les trois clients sur un seul émulateur ; l'écart de la paire de clés est décrit plus bas
La forme des requêtes et des réponses, champ par champ	oui, avec un plafond énoncé et un écart connu (PublicKey)	chaque réponse est vérifiée contre la description d'API du fournisseur
Que votre client lit un champ que le vrai cloud renvoie	oui, là où un enregistrement existe	les enregistrements de formes arbitrent ; l'angle mort est compté
L'ordre des dépendances : ce qui refuse d'être supprimé	oui, tant que la relation est synchrone	les assertions de refus de chaque suite
Que votre code décode un refus	oui	chaque suite exige des refus et échoue s'il n'y en a pas
Cloud-init, une connexion SSH, un pare-feu qui filtre	avec un runtime	dépend de la capacité firewall déclarée par l'hôte
Deux VPC qui ne peuvent pas se joindre	OVN seulement	dépend de la capacité isolation, jamais d'un nom de mode
Un répartiteur de charge qui distribue vraiment	OVN, et selon le pack	il faut que le runtime sache et que le pack délègue
Qu'une machine annoncée running existe sur l'hôte	OVN, par fournisseur	une suite lit les affirmations de l'API puis les vérifie avec incus
Atteindre une adresse privée depuis l'hôte	selon le mode	dépend de la capacité private_from_host
Un test au niveau du noyau : sysctl, modules, démarrage	avec un runtime VM	un conteneur partage le noyau de l'hôte
Le retry et le backoff face à un 429, un 5xx ou une panne	oui, sur les opérations que vous armez	l'injection de fautes, déterministe et éteinte par défaut
Qu'un identifiant d'image ou de type erroné soit rejeté	oui, sur demande	--strict-catalog refuse ce qui sort du catalogue que vous déclarez
Les quotas, la capacité réelle, les prix	non	le catalogue est une liste blanche mesurée
L'authentification et les permissions IAM	non	l'authentification est acceptée, jamais vérifiée
Une ressource qui reste en provisioning un moment	oui, sur demande	--consistency eventual fait avancer les états, une transition par lecture
Le stockage objet, et tout ce qui s'adresse en s3.<région>	non	non émulé, et le trafic part vraiment
Terraform contre Exoscale	oui, depuis le provider 0.71.0	les versions antérieures sont refusées par agent utilisateur
Le multi-zone ou le multi-région chez Exoscale	non	une zone par processus, et la raison vient du client
Du trafic qui traverse réellement une passerelle ou du NAT	non	les enregistrements bougent, les paquets non

Glissez pour voir

Comment lire un verdict

« oui » signifie qu'un vrai client a piloté cette opération dans l'exécution de référence, et que la suite a affirmé quelque chose de la réponse. Cela ne veut pas dire que chaque champ de chaque réponse est correct : deux défauts sont restés des mois derrière un axe pourtant vert, et c'est exactement pourquoi le projet publie plusieurs axes de mesure indépendants (sept en 0.13.0) sans jamais les additionner.

« avec un runtime » signifie que le plan de contrôle répond sans lui, et que l'affirmation ne tient que si les machines sont réelles. La bonne façon de savoir est de demander à l'émulateur plutôt que de deviner :

curl -s localhost:4599/_feint/health | jq .capabilities

{
  "machines": false,
  "addresses": false,
  "firewall": false,
  "isolation": false,
  "own_kernel": false,
  "balancing": false,
  "private_from_host": false
}

Une capacité que personne ne déclare est lue comme absente, délibérément : un contrôle se saute lui-même plutôt que d'affirmer ce qu'aucun pilote n'a promis. Ce que chaque mode livre est détaillé dans Faire tourner de vraies machines.

« non » est une décision avec une raison, pas un oubli. Plusieurs de ces lignes changeraient si quelqu'un faisait le travail correspondant, et ce sont alors des tickets ouverts, pas des omissions.

Un « oui » a aussi ses écarts connus, et il faut les lire. Avec Feint 0.13.0, l'action CreateKeypair d'Outscale attend la clé publique en clair, alors que l'API réelle exige du Base64 et que le client officiel octl l'encode lui-même depuis un fichier (--PublicKey ./id.pub). Contre l'émulateur, cette commande échoue donc avec l'erreur 4001, PublicKey is not an OpenSSH public key, alors qu'elle réussit contre le vrai Outscale : l'exemple complet est dans Brancher les CLI officiels. Une requête directe avec curl, clé en clair, passe sur Feint et échouerait sur le vrai service.

La limite la plus importante : une exécution locale peut joindre le vrai cloud

C'est la seule limite de cette page qui peut vous coûter de l'argent. Feint sert des API en local ; un client peut composer lui-même l'adresse d'un produit hors de ce périmètre, et ses requêtes repartent alors là où elles allaient.

Le cas mesuré est le stockage objet. Sur une configuration réelle, le même apply a créé son adresse IP sur l'émulateur puis a poursuivi vers s3.fr-par.scw.cloud, parce que le provider Terraform code cette adresse en dur pour ce produit. Seule une réponse 403 sur des identifiants factices a rendu l'opération inoffensive ce jour-là.

La parade, avant l'apply

Lancez feint doctor depuis le répertoire de votre configuration. La commande lit vos fichiers Terraform et signale les signatures d'échappement connues avant que quoi que ce soit ne parte :

ok    no known escape signature in the 1 Terraform file(s) here
      this checks the measured list (docs/limits.md), not every path a client
      could compose

La seconde ligne est aussi importante que la première : le contrôle couvre les cas mesurés, pas tous les chemins qu'un client pourrait composer. Pour une configuration de production dont vous n'êtes pas certain, coupez la sortie réseau du processus plutôt que de faire confiance à une liste.

Les cinq refus, et leurs raisons

Ces cinq lignes reviennent le plus souvent, et chacune est un arbitrage explicite plutôt qu'un travail non fait.

Les identifiants ne sont vérifiés contre rien, sauf si vous le demandez. Par défaut, une création qui nomme une image ou un type de machine inexistant réussit : Scaleway répond 201 pour un UUID d'image qui n'existe nulle part, Outscale accepte ami-99999999. Les vrais clouds refusent l'une comme l'autre. Ce défaut n'est pas une négligence : l'émulateur n'a pas d'inventaire, donc les seuls identifiants qu'il pourrait reconnaître sont ceux qu'il invente, et une configuration qui code en dur un identifiant de production échouerait alors sur la seule chose qui n'a rien à voir avec ce qu'elle teste.

Le coût était réel, et la 0.13.0 donne de quoi le supprimer quand il gêne : --strict-catalog prend un fichier JSON où vous déclarez, par fournisseur, les images, gabarits et types de machines que votre projet autorise.

{
  "scaleway": {"images": ["ubuntu_jammy"], "types": ["DEV1-S"]},
  "outscale": {"images": ["ami-fe1a7001"], "types": ["tinav6.c1r1p2"]},
  "exoscale": {"templates": ["Linux Ubuntu 22.04 LTS 64-bit"], "types": ["standard.medium"]}
}

Une création qui en sort est alors refusée dans la forme d'erreur propre à chaque cloud, pas dans un format maison : votre client rend son message habituel de ressource introuvable.

{"Errors":[{"Code":"5023","Details":"The ImageId 'ami-99999999' doesn't exist.","Type":"InvalidResource"}]}

Sans l'option, rien ne bouge : le mode de compatibilité est identique octet pour octet, et la phrase du dessus reste vraie mot pour mot. Un fournisseur que le fichier ne mentionne pas n'est pas contrôlé.

L'authentification est acceptée, jamais vérifiée. Aucune signature n'est contrôlée, sur aucun fournisseur. Les identifiants doivent seulement être bien formés, parce que les SDK en valident la forme côté client avant d'envoyer quoi que ce soit. La conséquence est directe : n'exposez jamais Feint sur un réseau que vous ne contrôlez pas. C'est un outil de développement qui accorde tout à tout le monde, par construction.

Le catalogue est une liste blanche mesurée. Les types de machines, les images et leurs attributs viennent de valeurs relevées chez le fournisseur, pas d'un inventaire vivant. Les quotas, la capacité réelle et les prix n'y figurent donc pas. Un exo limits répond, mais la limite affichée est une valeur fixe de l'émulateur, l'usage affiché est celui que l'émulateur a enregistré, et aucun refus de quota n'est jamais émis : 105 instances créées pour une limite affichée de 100 ont toutes été acceptées (Feint 0.13.0). Aucun test de dépassement de quota n'a de sens ici.

Les transitions de cycle de vie sont immédiates par défaut. Un serveur passe de stopped à running pendant l'appel. Les états que les clients vérifient sont préservés, par exemple le refus de supprimer un serveur en cours de transition dont Terraform dépend. Mais un refus qui n'existerait que pendant un état transitoire ne peut pas se produire : sur un vrai compte Outscale, un instantané demandé avant qu'un volume ne se stabilise est refusé, alors qu'ici le volume est disponible tout de suite. Un script qui enchaîne les deux réussit en local et peut échouer sur le vrai cloud. Depuis la 0.13.0, l'option --consistency eventual fait passer les ressources par ces états transitoires et rend ce refus atteignable, comme le montre Provoquer une panne d'API.

Le trafic ne traverse pas les passerelles. Chez Outscale, une passerelle ou du NAT déplacent des enregistrements, pas des paquets. La configuration s'applique, se replanifie à vide et se détruit ; ce qui n'existe pas, c'est le chemin réseau derrière.

Le plancher de version qui vous protège : Terraform et Exoscale

Terraform pilote Exoscale depuis la version 0.71.0 du provider, et les versions antérieures sont refusées. Ce n'est pas une lubie : jusqu'à cette version, le provider publié construisait deux clients et un seul honorait la variable EXOSCALE_API_ENDPOINT, si bien qu'un apply ou un destroy se scindait entre l'émulateur et un compte facturé.

Ce n'était pas une crainte théorique. Un feint down lancé dans le répertoire de la stack d'exemple a envoyé cinq requêtes signées vers les serveurs d'Exoscale. L'émulateur a donc refusé ce client pendant dix jours, du 26 août au 5 septembre 2026, le temps que le correctif arrive en amont.

Depuis, le refus s'est transformé en plancher. Un provider plus ancien que 0.71.0 est reconnu à son agent utilisateur et reçoit un 400 qui nomme la version à épingler ; à partir de 0.71.0, l'apply passe. Deux conséquences concrètes pour qui suivait l'ancienne procédure : feint up ne s'arrête plus au seuil, et la variable FEINT_EXOSCALE_ALLOW_TERRAFORM a disparu, faute d'avoir encore quelque chose à lever. Le CLI exo, lui, n'a jamais été concerné et pilote ce fournisseur de bout en bout.

Pourquoi aucun pourcentage n'est publié

C'est un choix de méthode, et il explique la forme de toute cette page. Un chiffre unique laisse une affirmation faible profiter d'une forte. Dire « 94 % de couverture » mélangerait des opérations dont le comportement est démontré avec d'autres qui répondent seulement quelque chose de bien formé.

Le projet publie donc, pour la 0.13.0, deux nombres qui ne s'additionnent pas : 395 opérations montées, dont 375 pilotées par un vrai client dans l'exécution de référence. Les 20 restantes déclarent, à leur route, pourquoi aucun client officiel ne les atteint. La différence entre « monté », « sondé » et « piloté » est développée dans Mesurer la fidélité.

Mettre en pratique

Le challenge 1 clôt le module : un environnement de la boutique est déjà déployé sur Feint, avec quelques restes d'essais oubliés, et la direction fixe un plafond mensuel. Vous ne modifiez rien : vous lisez l'inventaire avec scw, vous chiffrez chaque ressource avec la grille datée fournie (Feint ne connaît pas les prix, comme la matrice ci-dessus le dit) et vous listez ce qui se paie pour rien. Comme tout challenge, il se joue sans procédure pas à pas, et dsoxlab note votre estimation et votre liste.

Challenge Preuve

Résoudre sans procédure détaillée

Challenge 1 : architecture à budget contraint

$ dsoxlab run pratiquer-challenge-budget-contraint

Environnement : Shell·Durée : ~45 min

Vérification : la sortie produite est comparée au résultat attendu.

Première fois ? Qu'est-ce que DSOXLab et comment l'installer

DSOXLab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Il faut Python 3.11 ou plus récent, uv ou pipx, et git. Le guide d'installation détaille ces prérequis ; sous Windows, ou sur un Mac sans Python, passez plutôt par l'appliance.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/cloud-dsoxlab-training

Avant de lancer le lab, vérifiez :

• DSOXLab installé
• catalogue disponible
• environnement compatible (shell isolé ou VM)

Pour le vérifier, rien n'est sondé depuis cette page : lancez dsoxlab doctor. Lire le diagnostic

Lancer ce lab, puis valider votre travail :

dsoxlab run pratiquer-challenge-budget-contraint
dsoxlab check pratiquer-challenge-budget-contraint

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille le calcul du score et les pièges.

À retenir

• Le contrat d'API et le cycle de vie sont testables ; les prix, quotas et permissions ne le sont pas.
• Un « non » est une décision datée, avec une raison écrite, jamais un oubli.
• Une exécution locale peut joindre le vrai cloud : le stockage objet en est le cas mesuré.
• Les identifiants ne sont pas vérifiés : une faute de frappe passe ici et casse en production, sauf si vous déclarez un catalogue avec --strict-catalog.
• L'authentification n'est jamais contrôlée, donc l'émulateur ne s'expose pas sur un réseau ouvert.
• Les transitions sont immédiates par défaut : un refus propre à un état transitoire ne se reproduit qu'avec --consistency eventual.
• Aucun pourcentage n'est publié, parce qu'un chiffre unique masquerait les affirmations faibles.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →