Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Comprendre les codes d'état RFC
Les codes d'état RFC vous aident à suivre vos demandes. Vous pouvez observer ces codes d'état lors de l'exécution d'une RFC dans la sortie de la CLI ou en actualisant la page de liste des RFC dans la console.
Vous pouvez également voir les codes d'une RFC sur la page de détails de cette RFC, qui peut ressembler à ceci :
Il se peut que votre liste contienne une RFC que vous n'avez pas soumise. Lorsque les opérateurs AMS utilisent un CT interne uniquement, ils le soumettent dans une RFC et celui-ci s'affiche dans votre liste de RFC. Pour de plus amples informations, veuillez consulter Types de modifications internes uniquement.
Important
Vous pouvez demander des notifications en cas de changement d'état de la RFC. Pour plus de détails, voir Notifications de changement d'état RFC.
| Réussite | Échec |
|---|---|
|
Modification : le RFC a été créé mais n'a pas été soumis PendingApproval /Soumis : Le RFC a été soumis et le système détermine s'il doit être approuvé, et obtient cette approbation, si nécessaire Approuvé par AWS/Approuvé par le client : le RFC a été approuvé. RFCs Les automatismes sont approuvés par AWS, RFCs les manuels sont approuvés par les opérateurs et, parfois, par les clients Planifié : la RFC a passé avec succès les vérifications de syntaxe et d'exigences et son exécution est prévue InProgress: le RFC est en cours d'exécution, notez RFCs que le provisionnement de plusieurs ressources ou s'il est de longue durée prend plus de temps à exécuter UserData Exécuté : La RFC a été exécutée Succès/Réussite : La RFC a été terminée avec succès |
Rejetés : RFCs sont généralement rejetés parce qu'ils échouent à la validation ; par exemple, une ressource inutilisable, c'est-à-dire un sous-réseau, est spécifiée Annulés : RFCs sont généralement annulés parce qu'ils ne passent pas la validation avant l'expiration de l'heure de début configurée Échec : le RFC a échoué ; consultez le résultat pour StatusReason les raisons de l'échec, et les opérations AMS créent automatiquement un ticket d'incident et communiquent avec vous selon vos besoins |
Note
Les demandes annulées ou rejetées RFCs peuvent être soumises à nouveau en utilisant UpdateRfc; voir égalementMettre à jour RFCs.
Si la RFC satisfait à toutes les conditions nécessaires (par exemple, tous les paramètres requis sont spécifiés), le statut passe à PendingApproval (même une approbation automatique est CTs requise, ce qui se produit automatiquement si les vérifications de syntaxe et de paramètres sont réussies). S'il ne passe pas, le statut passe àRejected. Le StatusReason fournit des informations sur les rejets ; les ExecutionOutput champs fournissent des informations sur l'approbation et la finalisation. Les codes d'erreur incluent :
InvalidRfcStateException: Le statut de la RFC n'autorise pas l'opération appelée. Par exemple, si la RFC est passée à l'état Soumis, elle ne peut plus être modifiée.
InvalidRfcScheduleException: Les TimeoutInMinutes paramètres StartTime EndTime, ou ont été violés.
InternalServerError: Le système a rencontré un problème.
InvalidArgumentException: Un paramètre est mal spécifié ; par exemple, une valeur inacceptable est utilisée.
ResourceNotFoundException: aucune valeur, telle que l'ID de pile, est introuvable.
Si les heures de début et de fin planifiées demandées (également appelées fenêtre d'exécution des modifications) se produisent avant que la modification ne soit approuvée, le statut de la RFC passe àCanceled. Si la modification est approuvée, le statut de la RFC passe àScheduled. La fenêtre de modification pour ASAP RFCs correspond à l'heure de soumission plus la ExpectedExecutionDuration valeur du CT.
À tout moment avant l'arrivée de la fenêtre d'exécution des modifications, une modification planifiée (soumise avec un RequestedStartTime dans la CLI) peut être modifiée ou annulée. Si la modification planifiée est modifiée, elle doit ensuite être soumise à nouveau.
Lorsque l'heure de début des modifications arrive (planifiée ou dès que possible) et une fois les approbations terminées, le statut change InProgress et aucune modification ne peut être apportée. Si la modification est terminée dans la fenêtre d'exécution des modifications spécifiée, le statut passe àSuccess. Si une partie de la modification échoue, ou si la modification est toujours en cours à la fin de la fenêtre d'exécution des modifications, le statut passe àFailure.
Note
Pendant l'état InProgress ou le Failure changement d'état, le RFC ne peut pas être modifié ou annulé. Success
Le schéma suivant illustre les statuts RFC depuis l'appel CreateRFC jusqu'à la résolution.
