Validation de la configuration

Le daemon valide le document principal avant la normalisation DWho et vérifie le catalogue combiné des points d’entrée après les imports. Les noms des plugins sont des chaînes non vides ; config, users, vars et discovery sont des mappings. Les chemins d’import des composants sont des chaînes, ou null pour un import facultatif inutilisé. Les anciens composants Mako doivent produire des mappings, conformément au contrat existant du catalogue. Les limites du catalogue importé, les chemins du fichier déclarant, les priorités des définitions en ligne, la découverte, l’authentification et les limites des tâches restent contrôlés par leurs services respectifs. Les champs inconnus des plugins sont conservés. Le chargeur distinct des cibles et scénarios clients ne change pas.

XYS (Sonicprobe >= 0.3.57) valide les données Python analysées ; il ne remplace pas le chargeur YAML, ne résout pas les imports, n’initialise pas de services et n’accorde aucune permission. Les schémas sont compilés une seule fois, sans modificateurs ni conversion implicite des valeurs. La normalisation numérique et les contrôles sémantiques existants restent applicables.

Les champs applicatifs connus sont validés explicitement. Les paramètres d’extension restent possibles lorsque le contrat existant le permet ; cela ne détecte pas toutes les fautes de frappe dans les plugins. Les structures de section ou de composant mal formées produisent une erreur de configuration plutôt qu’une exception incidente d’attribut ou de mise à jour. Les nouvelles erreurs n’incluent ni les valeurs de configuration ni le contenu des identifiants.

tests/test_configuration_schema.py couvre les structures valides et invalides ainsi que la compatibilité à la frontière du chargeur. Exécutez le contrôle de collecte avant la suite unittest :

python .github/scripts/check-test-collection.py --runner unittest tests
python -m unittest discover -s tests -v

Ces tests utilisent des données synthétiques et des adaptateurs simulés ou des services locaux. Ils ne démontrent ni la disponibilité des fournisseurs ni l’acceptation en production.

Vérifier hors ligne les réglages prévus pour la 2.0

Avant de modifier une installation, lancez autond --check-migration -c /etc/auton/auton.yml. La commande examine le fichier YAML et ses catalogues pour repérer le mode legacy implicite et les cibles qui autorisent le client à choisir les fichiers d’environnement. Le code 0 indique qu’aucun de ces points n’a été relevé, le code 1 signale un élément à examiner et le code 2 indique que la configuration n’a pas pu être inspectée. Un mode d’authentification explicite sort du périmètre du contrôle du mode implicite.

Les réglages définis directement dans la cible sont prioritaires. Lorsqu’un réglage dépend de import_config, le diagnostic demande une vérification manuelle sans exécuter le template. Les avertissements de démarrage et de première utilisation introduits en 1.3.6 distinguent la permission de l’usage réel. Les fichiers déclarés dans config.envfiles restent utilisables. La commande lit le fichier fourni avec -c, sans démarrer le démon, ouvrir ses bases, lire les fichiers d’environnement ni vérifier les identifiants. Pour une installation utilisant AUTOND_CONFIG, examinez un fichier local équivalent.