Profil S4 : scénarios de test du CTK¶

Version 0.3 · 31 octobre 2026 · draft · PDF

Cette note spécifie les scénarios du Compliance Test Kit (CTK) du profil S4, consacré à la réversibilité du stockage objet compatible S3. Chaque scénario vérifie des contrats comportementaux et alimente des critères de la scorecard. La note fixe aussi les jeux de données de référence, les verdicts, le format du rapport et celui du manifeste d'export.

Les scénarios CTK-01 à CTK-06 ont été retenus par l'atelier OpenInterop du 9 octobre 2026 ; ils restent soumis à la validation du groupe de travail. Une implémentation, le CTK S4, couvre déjà CTK-01 à CTK-05. Chaque scénario se termine ci-dessous par une courte ligne d'état ; la note sur le CTK S4 décrit l'implémentation, son usage et les résultats des premiers essais.

1. Principes¶

• Une exigence vaut par son test. Chaque scénario renvoie aux contrats et aux critères de la scorecard qu'il évalue.
• Structure commune : préconditions, action, données, résultat attendu, mesure, seuil, verdict.
• Une preuve reproductible. L'acheteur peut exécuter, ou faire exécuter, un test versionné sur un jeu de données connu, puis obtenir un rapport vérifiable. Le rapport identifie le service, sa version et les fonctions revendiquées, le profil et la version du CTK, le jeu de données et les conditions d'exécution, les résultats, écarts et limites, ainsi que la commande qui rejoue le test (§6).
• Un transfert par un outil indépendant. La migration passe par un outil qui n'appartient ni au fournisseur source (A) ni au fournisseur cible (B), par copie directe ou par un export intermédiaire. Le rapport décrit le chemin suivi.
• Une source figée. Les écritures sont suspendues pendant le test. La migration pendant les écritures relève d'un périmètre ultérieur.
• Assembler l'existant : s3-tests (Ceph) pour les tests unitaires de conformité, rclone ou un client de référence équivalent pour les transferts, enfin les composants propres au CTK S4 (générateur de données, manifeste, comparateur).
• Des cibles de référence pour le réimport : Ceph RGW et Garage, déployés dans des conteneurs aux versions fixées. Les essais croisés visent en outre au moins deux fournisseurs indépendants.

Le CTK produit une preuve technique, au sens de la doctrine OpenInterop (§5.3) : autoévaluation quand le fournisseur l'exécute lui-même, vérification quand un tiers l'exécute, essai croisé quand plusieurs fournisseurs l'exécutent les uns vers les autres. Son usage dans un contrat demande une clause rédigée à part ; une proposition d'annexe contractuelle est prévue pour décembre 2026 (§7).

1.1 Verdicts¶

Chaque critère reçoit l'un des quatre verdicts de la doctrine. Le rapport les code en anglais.

Une règle s'applique à tous les scénarios : le service n'est pas conforme au profil testé si un objet manque, si un contenu est corrompu ou si un accès interdit devient autorisé. Les critères obligatoires ne se compensent pas et ne font l'objet d'aucune moyenne pondérée. Les performances et les coûts qualifient ensuite les conditions de la réversibilité sans racheter ces échecs. Le verdict global d'une exécution est non conforme dès qu'un critère l'est, non concluant dès qu'un critère l'est, conforme sinon.

1.2 Contenu de chaque fiche de test¶

Outre la structure commune, chaque fiche précise les versions, paramètres et commandes, les preuves conservées, les conditions d'arrêt ainsi que les fonctions obligatoires et optionnelles du périmètre.

2. Jeux de données de référence¶

Les jeux sont produits par le générateur du CTK à partir d'une graine publiée : même graine, mêmes clés, mêmes tailles, mêmes octets, mêmes métadonnées. Leur contenu et leurs sommes de contrôle sont donc connus à l'avance et identiques pour tous les fournisseurs. Ils sont synthétiques et ne contiennent aucune donnée personnelle. Chaque jeu est accompagné de son manifeste de référence (annexe A), qui sert d'oracle pour les comparaisons ; le rapport publie l'empreinte SHA-256 de ce manifeste.

2.1 Volumes¶

L'atelier a retenu deux volumes ; le CTK S4 en ajoute un troisième pour les exécutions rapides.

Le volume de charge reste à confirmer selon les moyens des essais croisés.

2.2 Familles de contenu¶

Chaque volume forme un seul jeu, qui mêle cinq familles de contenu. Le tableau décrit chaque famille et la part que couvre le générateur actuel.

L'objet de 5 Mio + 1 octet, dont la dernière partie fait un octet, a mis au jour un défaut de Ceph RGW (§3, CTK-02).

3. Scénarios retenus¶

Vue d'ensemble¶

CTK-01 : Export complet¶

• Préconditions : source figée, manifeste de référence connu ; un contrat avec B et une connexion entre A et B sont établis ; identifiants programmatiques avec droits de lecture complets chez A et d'écriture chez B ; outil de transfert de référence installé à une version fixée.
• Action
• Charger le jeu fonctionnel dans un bucket de A.
• Produire l'inventaire de A sur plusieurs pages de listage et le comparer au manifeste de référence.
• Migrer vers B avec l'outil de référence, sans intervention manuelle.
• Produire l'inventaire de B et le comparer au manifeste de A.
• Données : jeu fonctionnel, dont DS-K.
• Résultat attendu : tous les objets attendus sont présents chez B avec les mêmes clés ; aucun objet inattendu n'apparaît dans le périmètre ; aucune clé n'est listée deux fois.
• Mesure : comptage et correspondance des clés ; doublons et omissions de pagination ; étapes manuelles.
• Seuil : 100 % de correspondance ; zéro objet en plus ; zéro intervention pendant l'exécution nominale.
• Verdict : A1, A5, A6, A7 et A9.
• Contrats couverts : EXP-01, EXP-03, EXP-04, API-01, API-04, API-05.
• État : implémenté pour A1, A6 et A7. L'export de la configuration du bucket (A5) n'est pas évalué ; A9 est constaté (aucune intervention) sans recevoir de verdict.

CTK-02 : Intégrité¶

• Préconditions : celles de CTK-01 ; les corruptions sont injectées dans une copie de test ou dans la cible, puis réparées avant la suite des vérifications.
• Action
• Migrer un mélange de tailles comprenant des objets multipartie.
• Calculer, pour chaque objet, la taille et l'empreinte SHA-256 du contenu complet, chez A puis chez B, indépendamment des ETags.
• Corrompre quelques objets (octet modifié, troncature, objet remplacé) et rejouer la vérification.
• Données : jeu fonctionnel, dont DS-L.
• Résultat attendu : les contenus valides sont reconnus ; chaque corruption injectée est détectée et localisée (clé, nature de l'écart).
• Mesure : objets dont taille et empreinte correspondent ; corruptions détectées sur corruptions injectées.
• Seuil : 100 % d'empreintes conformes sur les objets valides ; 100 % des corruptions détectées ; aucun faux verdict positif.
• Verdict : A2.
• Contrats couverts : INT-01, INT-02, INT-03.
• État : implémenté. Les trois corruptions sont injectées dans la cible, détectées par clé, puis réparées. Les essais ont révélé un défaut de Ceph RGW (v19.2.7 puis v20.2.4, sur le backend dbstore) : la lecture d'un objet multipartie dont la dernière partie fait un octet ne se termine pas. Ils ont aussi montré que boto3 (à partir de 1.36), avec sa validation des sommes de contrôle activée par défaut, rejette la réponse de Garage pour un objet multipartie. Le client de référence désactive donc cette validation et le CTK vérifie l'intégrité lui-même par SHA-256.

CTK-03 : Métadonnées et droits¶

• Préconditions : liste des champs obligatoires du profil arrêtée ; matrice d'accès définie, c'est-à-dire un ensemble d'identités (lecteur, rédacteur, administrateur, public anonyme) et, pour chacune, les opérations autorisées et interdites sur des objets désignés.
• Action
• Migrer le jeu fonctionnel, dont DS-M.
• Comparer, objet par objet, les champs obligatoires chez A et chez B.
• Reconstruire chez B les droits convenus, par les moyens propres au modèle IAM de B.
• Rejouer la matrice d'accès chez A puis chez B et comparer les décisions.
• Données : jeu fonctionnel, dont DS-M ; matrice d'accès.
• Résultat attendu : propriétés préservées ; valeurs d'origine non reproductibles (date de dernière modification, ETag) transportées ; mêmes décisions d'accès chez A et chez B ; aucune exposition publique involontaire.
• Mesure : champs obligatoires conformes sur champs attendus ; cas d'accès correctement appliqués sur cas prévus.
• Seuil : 100 % des champs et 100 % des cas d'accès obligatoires.
• Verdict : A3, A4, A7 et A10.
• Contrats couverts : MET-01 à MET-04, MET-06, SEC-01.
• État : implémenté pour A3, A4 et A10 (A7 est jugé dans CTK-01). Les valeurs d'origine de Last-Modified et de l'ETag sont copiées chez B en métadonnées utilisateur préfixées oi-orig-. La matrice d'accès est un fichier TOML (identités, opérations, décisions attendues) ; l'accès anonyme en lecture et en listage y est ajouté avec la décision attendue deny. Sans matrice, A10 reçoit le verdict non applicable. Si la source s'écarte déjà de la matrice, A10 est non concluant. Sur Garage, revendiquer les étiquettes donne un verdict non conforme sur A3 (GetObjectTagging non implémenté).

Les droits se comparent par leur effet sur les accès, car les modèles IAM diffèrent d'un fournisseur à l'autre. La gestion des identités et les droits nécessaires à l'export et à l'import relèvent aussi du socle transverse.

CTK-04 : Incident et reprise¶

• Préconditions : celles de CTK-01 ; liste d'incidents définie (coupure réseau d'une durée donnée, erreurs 5xx et SlowDown injectées, identifiants expirés en cours de transfert).
• Action
• Lancer la migration du jeu fonctionnel.
• Provoquer chaque incident à un moment défini, puis laisser l'outil reprendre.
• Comparer le résultat final au manifeste de référence.
• Données : jeu fonctionnel, dont DS-L.
• Résultat attendu : reprise automatique ; rapport explicite des incidents ; aucune perte ni duplication logique.
• Mesure : complétude et intégrité finales ; délai de reprise ; volume retransmis ; interventions nécessaires.
• Seuil : résultat final identique au manifeste ; seuils de délai et de retransmission à calibrer après les premiers essais.
• Verdict : A1, A2 et A6 ; B9 publié.
• Contrats couverts : API-02, API-03, REP-01.
• État : implémenté pour les coupures de connexion, injectées côté client au-delà des nouvelles tentatives du SDK ; A1 et A2 sont jugés ; incidents, reprises, octets retransmis et durée de reprise sont publiés (B9). Restent à ajouter les erreurs 5xx ou SlowDown ainsi que l'expiration d'identifiants.

CTK-05 : Exploitation et charge¶

• Préconditions : volume de charge ; application témoin (lecture, écriture, listage) et sa suite de tests ; durée d'engagement définie pour le scénario.
• Action
• Migrer le jeu de charge vers B.
• Révoquer tous les accès de l'application à A.
• Reconfigurer l'application vers B (adresse du point d'accès et identifiants uniquement), puis exécuter sa suite de tests.
• Données : jeu de charge.
• Résultat attendu : application opérationnelle sur B ; engagement de durée respecté.
• Mesure : tests applicatifs réussis sur tests prévus ; fonctions encore liées à A ; durée totale du lancement à la validation sur B ; débit utile.
• Seuil : 100 % des tests applicatifs du profil ; zéro dépendance résiduelle pour l'usage testé ; durée et débit publiés avec leurs conditions.
• Verdict : A8 et A11 ; B10 et B11 publiés.
• Contrats couverts : REC-01, REC-02, REC-04.
• État : implémenté. L'application témoin travaille sur B seul : lectures d'un échantillon vérifiées contre le manifeste, métadonnées, listage paginé, lectures partielles vérifiées contre les octets de référence (milieu de l'objet, frontière de partie, fin), lecture conditionnelle (If-Match, qui doit échouer avec 412 sur un ETag périmé), écriture. Quand les anciens identifiants de l'application chez A sont fournis, A doit les refuser (A8) ; sinon A8 est non applicable. Si A les accepte encore, A8 est non concluant. Les essais menés à ce jour sur Garage ont utilisé le volume d'essai rapide ; l'exécution au volume de charge est prévue avec les essais croisés.

CTK-06 : Performance de la migration¶

L'atelier a retenu ce scénario sans en fixer le contenu. Il vise à vérifier l'absence de limitation du transfert, à conditions d'infrastructure équivalentes. La méthode « déclaré puis vérifié » sert de point de départ :

• Préconditions : fiche de déclaration avec B1, B2, B3 et B7 ; client placé de sorte que le réseau ne limite pas la mesure ; capacité du lien mesurée et consignée ; quotas suffisants confirmés par le fournisseur.
• Action : lecture continue de DS-L au parallélisme déclaré pendant au moins 30 minutes (B1), même mesure sur plusieurs buckets (B2), courbe débit et parallélisme (B7), montée en charge des requêtes jusqu'aux premières réponses de limitation (B3).
• Mesure et seuil : valeurs mesurées comparées aux valeurs déclarées, avec une tolérance à fixer ; réponses de limitation conformes au profil.
• Conditions de comparaison : même jeu de données, même client, même concurrence, mêmes régions, mêmes quotas et même chemin réseau. Le rapport publie le débit réseau disponible et les temps d'inventaire, de transfert, de vérification et de reconstruction. Un seuil universel de débit serait prématuré.
• Contrats couverts : PERF-01 à PERF-04.
• État : non implémenté, en attente de la définition du scénario par le groupe de travail. Les mesures de débit du CTK S4 restent indicatives.

4. Scénarios complémentaires et périmètres avancés¶

Ces scénarios ne font pas partie du socle CTK-01 à CTK-06. Ils restent au backlog.

Sont aussi classés à part : versions historiques, marqueurs de suppression, stockage archivé, Object Lock, règles de cycle de vie, migration pendant les écritures, dépendances aux KMS, cohérence forte.

5. Architecture¶

Le CTK assemble les composants suivants. Leur conception et leur usage sont décrits dans la note sur le CTK S4.

Les composants nouveaux seront publiés sous une licence open source permissive ou faiblement copyleft, compatible avec les briques réutilisées ; le choix reste à arrêter avec OW2.

6. Format du rapport¶

Le rapport est un fichier JSON lisible par machine. Son empreinte est publiée et l'exécutant (fournisseur ou tiers) peut le signer. Il accompagne trois manifestes au format JSON Lines : référence, source et cible.

Exemple abrégé :

{
  "profile": "S4 draft",
  "features_claimed": ["core", "tags"],
  "source": {"name": "Fournisseur A", "version": "…", "endpoint": "https://…",
             "region": "…", "bucket": "…"},
  "target": {"name": "Garage", "version": "v1.0.1", "endpoint": "http://…",
             "region": "garage", "bucket": "…"},
  "environment": {"executor": "…", "transfer_path": "direct, through the machine running the kit",
                  "link_capacity_mbps": 1000, "boto3": "1.x",
                  "started_at": "2026-…", "finished_at": "2026-…"},
  "dataset": {"volume": "functional", "seed": 0, "objects": 10000,
              "bytes": 10000000000, "reference_manifest_sha256": "…"},
  "measures": {"transfer_seconds": 0.0, "bytes_copied": 0, "useful_throughput_mib_s": 0.0},
  "verdict": "NON_CONFORMANT",
  "results": [
    {"scenario": "CTK-03", "criterion": "A3", "verdict": "NON_CONFORMANT",
     "findings": 1, "evidence": {"…": ["…"]}}
  ],
  "limits": ["Source frozen during the run.", "…"],
  "reproduction": {"command": "…"}
}

7. Calendrier et TechSprint¶

L'atelier a proposé le calendrier suivant :

• Objectif du TechSprint : CTK-01 à CTK-03 exécutés contre les deux cibles de référence et au moins deux fournisseurs indépendants ; CTK-04 et CTK-05 en complément.
• Engagements recherchés : deux fournisseurs indépendants (environnements, documentation, essais), un utilisateur (critères de réception, scénario applicatif), des développeurs du CTK et un référent sécurité (matrice d'accès).
• Livrables : premiers rapports CTK, liste des écarts constatés sur le profil, signalements aux projets amont (dont le défaut de Ceph RGW).

8. Points ouverts¶

• Liste des champs obligatoires de CTK-03 et transformations admises.
• Format de la matrice d'accès : le format TOML du CTK S4 est une proposition.
• Contenu de CTK-06, tolérances entre valeurs déclarées et mesurées.
• Seuils de délai et de retransmission de CTK-04.
• Volume de charge définitif, selon les moyens des essais croisés.
• Compléments du générateur pour couvrir entièrement DS-S, DS-L, DS-M et DS-K (§2.2), puis DS-V.
• Export de la configuration du bucket (A5) et en-tête d'export (annexes A.2 et A.3), non encore implémentés.
• Licence des composants nouveaux.

Annexe A. Manifeste d'export¶

Le manifeste utilise le format JSON Lines, avec une ligne par objet (par version dans le périmètre versionné). La configuration du bucket figure dans un fichier séparé. Un en-tête d'export indique le fournisseur, le bucket, la date, la version du schéma et les algorithmes. Une variante Parquet pourra servir aux très gros inventaires. Lorsque les données et le manifeste sont livrés ensemble, l'empaquetage s'inspire de BagIt (RFC 8493).

Le schéma JSON des entrées (version 0.1, JSON Schema 2020-12) couvre le niveau Core et les étiquettes. Le CTK S4 l'emploie pour valider ses propres manifestes et ceux que fournit un service. Un manifeste de référence indique null pour les champs attribués par le serveur (last_modified, etag).

A.1 Entrées objet¶

Champs du schéma 0.1. Tous sont présents dans chaque entrée, avec la valeur null quand l'objet n'a pas ce champ ; aucun autre champ n'est admis. Ce choix facilite la comparaison des manifestes.

Les versions suivantes du schéma ajouteront les champs ci-dessous.

A.2 Configuration du bucket¶

La configuration du bucket n'a pas encore de schéma et le CTK S4 ne la produit pas.

A.3 En-tête d'export¶

L'en-tête n'a pas encore de schéma et le CTK S4 ne le produit pas.