> ## Documentation Index > Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt > Use this file to discover all available pages before exploring further. # Cycle de vie > Contrat d’exécution pour la ressource personnalisée Vantage : phases de réconciliation, conditions d’état et forçage d’une nouvelle tentative. Cette page décrit le contrat d’exécution entre vous et le opérateur Vantage : les phases que l’opérateur exécute à chaque réconciliation, les conditions qu’il publie sur la ressource `Vantage` et la manière de forcer une nouvelle tentative. Pour le schéma des champs, consultez la [référence de l’API](/fr/vantage/self-hosted/v3.0/api-reference). Pour une vue d’ensemble conceptuelle, consultez [Architecture](/fr/vantage/self-hosted/v3.0/architecture).
## Phases de réconciliation
La réconciliation de l’opérateur est structurée en cinq phases séquentielles. Chaque phase contient des validateurs ou des étapes qui doivent tous réussir avant que l’opérateur ne passe à la phase suivante. L’échec d’une seule étape est fatal à la réconciliation et apparaît dans `status.degradationReasons[]`. | # | Phase | Ce qui se passe | | - | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Vérifications préalables** | Valide la configuration. Lors des vérifications préalables, la configuration des secrets est validée. | | 2 | **Secrets** | Garantit l’existence des ressources liées aux secrets pour le provider de secrets configuré. Pour le provider Azure Key Vault, l’opérateur provisionne des ressources `SecretProviderClass` pour chaque chart ; le Secrets Store CSI driver fournit les valeurs aux pods au démarrage. L’opérateur ne matérialise pas lui-même les valeurs des secrets. | | 3 | **Migration OCI** | Exécute le job ponctuel qui copie les artifacts Vantage depuis le registry source distribué par ABBYY vers le registry de destination déclaré dans `spec.ociMigration.destination`. Ignoré lorsque `spec.ociMigration.enabled: false`. | | 4 | **Installation** | Génère les manifestes ArgoCD `Application` pour chaque composant Vantage à partir de la ConfigMap des charges de travail, puis les applique. | | 5 | **Synchronisation** | Surveille l’état des applications ArgoCD, remonte les erreurs propres à chaque composant via `status.degradationReasons[]` et met à jour les conditions `Progressing`, `Ready` et `Degraded` en conséquence. |
## Conditions d'état
L'opérateur publie l'état de l'installation via des types de condition dans `status.conditions[]` : * **`Progressing`** : `status` vaut `True` tant que le processus est en cours. * **`Ready`** : `status` vaut `True` en cas de réussite. * **`Degraded`** : `status` vaut `True` si une erreur survient à un moment quelconque. Dans ce cas, `status.degradationReasons[]` contient les détails de la ou des erreurs. Les procédures d'installation Azure et autogérées attendent `condition=Ready` (`kubectl wait --for=condition=Ready vantages.vantage.abbyy.com/$release_name`). `Ready` ne couvre pas l'installation des compétences, qui s'exécute dans le cadre d'un job distinct (voir ci-dessous), et vous devez également vérifier les applications ArgoCD générées. Consultez la [référence `Vantage.status`](/fr/vantage/self-hosted/v3.0/api-reference#vantagestatus) pour le schéma d'état complet.
### L’installation des compétences s’exécute séparément
Les compétences sont installées par un job Kubernetes distinct dans le namespace d’installation, et non par une application ArgoCD. Ce job n’apparaît pas dans ArgoCD et n’est pas pris en compte dans les conditions ci-dessus. Par conséquent, `Ready` n’indique pas que l’installation des compétences est terminée. Vous pouvez utiliser Vantage pendant l’exécution du job. Surveillez directement le job : ```bash theme={null} kubectl -n $install_namespace wait --for=create job/$install_namespace-skill-installer-job kubectl -n $install_namespace wait --for=condition=Complete job/$install_namespace-skill-installer-job ```
## Forcer une nouvelle tentative
Pour relancer l’installation (par exemple, après avoir corrigé une autorisation dans Key Vault), annotez la ressource `Vantage` avec `vantage.abbyy.com/reprocess` (n’importe quelle valeur) : ```bash theme={null} kubectl -n $install_namespace annotate vantages.vantage.abbyy.com/$release_name \ vantage.abbyy.com/reprocess="$(date +%s)" --overwrite ``` La ressource personnalisée `Vantage` est modifiable, mais pour relancer l’installation de Vantage, la CR `Vantage` correspondante doit être annotée avec `vantage.abbyy.com/reprocess` (n’importe quelle valeur). Modifier uniquement `spec.*` ne relance pas une installation en échec ; après avoir corrigé la spécification, ajoutez l’annotation pour déclencher une nouvelle tentative.
## Et ensuite
Référence champ par champ de toutes les propriétés spec et status. Symptôme → diagnostic → correction des échecs de réconciliation courants.