Rollback¶

L'option rollback est un mécanisme de sécurité disponible dans les opérations de déploiement de configuration (Maps, Règles d'ingénierie, Planificateur). Lorsqu'elle est activée, Avalon annule automatiquement les modifications de configuration en cas d'échec pendant le déploiement, garantissant que vos équipements retournent à leur état stable précédent.

Quand utiliser le rollback¶

Activez le rollback lorsque :

Vous déployez des modifications de configuration critiques sur des équipements de production
Vous exécutez des opérations pendant des fenêtres de maintenance où la stabilité est primordiale
Vous testez de nouvelles configurations et souhaitez un filet de sécurité automatique

Comment fonctionne le rollback¶

Comportement général¶

Le rollback est un mécanisme au niveau de la transaction, ce qui signifie qu'il opère au niveau de la transaction et crée un point de contrôle au début de chaque transaction.

Avant le déploiement : Avalon crée un point de restauration (checkpoint) en sauvegardant la configuration courante de tous les équipements impliqués dans la transaction.
Pendant le déploiement : Avalon applique les modifications de configuration aux équipements en séquence.
Si un échec survient : Le rollback déclenche les actions suivantes selon le statut de l'équipement :
- Équipements réussis (déjà configurés) : Avalon revient à la configuration du point de restauration de la transaction courante. Ces sous-transactions sont marquées comme ROLLED_BACK.
  
  Transactions précédentes réussies
  
  Si l'équipement a été configuré par une transaction précédente qui s'est terminée à 100% avec succès, cette configuration précédente reste intacte. Seule la transaction courante échouée est annulée.
- Équipement en échec (où l'erreur s'est produite) :
  - Si l'équipement est joignable : La configuration est revenue au point de restauration. Sous-transaction marquée comme ROLLED_BACK.
  - Si l'équipement est injoignable : La configuration peut avoir changé ou non selon le moment où la connectivité a été perdue. Sous-transaction marquée comme FAILED.
- Équipements en attente (positionnés après l'équipement en échec dans la séquence) : Les modifications de configuration ne sont pas appliquées du tout. Sous-transactions marquées comme SKIPPED.
Nettoyage : Les points de restauration sont supprimés pour tous les équipements joignables dans tous les cas (que le rollback ait été déclenché ou non).

Comportement multi-transaction¶

Pour les opérations impliquant plusieurs transactions (services composites, règles d'ingénierie multi-services, règles d'ingénierie multi-règles) :

Transactions terminées : Toutes les transactions qui se sont terminées à 100% avec succès ne sont pas affectées par le rollback.
Transaction échouée : Lorsqu'un échec survient, la transaction courante est annulée comme décrit ci-dessus.
Transactions suivantes : Toutes les transactions restantes dans la séquence sont abandonnées et ne s'exécuteront pas.

Exemple : Si un service composite inclut 3 services, et que le 2ème service échoue :

Service 1 : ✅ Terminé avec succès → la configuration reste appliquée
Service 2 : ❌ Échec → rollback déclenché, équipements revenus à l'état précédent
Service 3 : ⏭️ Ignoré → jamais exécuté

Diagramme de processus¶

graph TD
    Start[Début de la transaction] --> Checkpoint[Créer un point de restauration<br/>sur tous les équipements]
    Checkpoint --> Deploy[Déployer la configuration<br/>sur les équipements en séquence]
    Deploy --> Check{Résultat du<br/>déploiement ?}

    Check -->|Tous réussis| Success[Tous les équipements configurés]
    Success --> Cleanup1[Supprimer les points de restauration]
    Cleanup1 --> End1[Transaction : SUCCESS]

    Check -->|Échec survenu| Rollback[Rollback déclenché]
    Rollback --> Successful[Équipements réussis :<br/>Revenir au checkpoint<br/>Statut : ROLLED_BACK]
    Rollback --> Failed{Équipement en échec<br/>joignable ?}
    Failed -->|Oui| FailedRevert[Revenir au checkpoint<br/>Statut : ROLLED_BACK]
    Failed -->|Non| FailedUnreach[Impossible de revenir<br/>Statut : FAILED]
    Rollback --> Pending[Équipements en attente :<br/>Ignorer la configuration<br/>Statut : SKIPPED]

    Successful --> Cleanup2[Supprimer les points de restauration]
    FailedRevert --> Cleanup2
    FailedUnreach --> Cleanup2
    Pending --> Cleanup2
    Cleanup2 --> End2[Transaction : FAILED]

    End2 -.-> Multi{Fait partie d'une<br/>multi-transaction ?}
    Multi -->|Oui| Abort[Abandonner les<br/>transactions restantes]
    Multi -->|Non| Final[Fin]
    Abort --> Final

    classDef successClass fill:#90EE90,stroke:#2E7D32,stroke-width:2px,color:#000;
    classDef failClass fill:#FFB6C1,stroke:#C62828,stroke-width:2px,color:#000;
    classDef skipClass fill:#FFE082,stroke:#F57C00,stroke-width:2px,color:#000;
    classDef neutralClass fill:#E3F2FD,stroke:#1565C0,stroke-width:2px,color:#000;

    class Success,Cleanup1,End1 successClass;
    class Rollback,FailedRevert,FailedUnreach,Cleanup2,End2,Abort failClass;
    class Pending,Successful skipClass;
    class Start,Checkpoint,Deploy,Check,Failed,Multi,Final neutralClass;

États des sous-transactions¶

Lors de la consultation des journaux de transaction, vous verrez ces états :

SUCCESS : L'équipement a été configuré avec succès et aucun rollback n'a été déclenché
ROLLED_BACK : L'équipement a été configuré avec succès mais a été ramené à l'état précédent en raison d'un échec ailleurs
FAILED : L'équipement a rencontré un échec et n'a pas pu être ramené à l'état précédent (généralement en raison d'une inaccessibilité)
SKIPPED : La configuration de l'équipement n'a jamais été tentée en raison d'un échec antérieur

Roadmap

Nous prévoyons de rendre l'option rollback configurable afin que les utilisateurs puissent décider d'annuler toutes les transactions dans un scénario multi-transaction (services composites, règles d'ingénierie multi-services/multi-règles), au lieu d'annuler uniquement la transaction échouée.