Skip to content

Rollback

The rollback option is a safety mechanism available in configuration deployment operations (Maps, Engineering Rules, Scheduler). When enabled, Avalon automatically reverts configuration changes if a failure occurs during deployment, ensuring your devices return to their previous stable state.

When to use rollback

Enable rollback when:

  • Deploying critical configuration changes to production devices
  • Executing operations during maintenance windows where stability is paramount
  • Testing new configurations where you want an automatic safety net

How rollback works

General behavior

Rollback is a transaction-wide mechanism, meaning it operates at the transaction level and creates a checkpoint at the beginning of each transaction.

  1. Before deployment: Avalon creates a restoration point (checkpoint) by saving the current running configuration of all devices involved in the transaction.

  2. During deployment: Avalon applies configuration changes to devices in sequence.

  3. If a failure occurs: Rollback triggers the following actions based on device status:

    • Successful devices (already configured): Avalon reverts the configuration to the restoration point of the current transaction. These subtransactions are marked as ROLLED_BACK.

      Previous successful transactions

      If the device was configured by a previous transaction that completed 100% successfully, that previous configuration remains intact. Only the current failed transaction is rolled back.

    • Failed device (where the error occurred):

      • If the device is reachable: Configuration is reverted to the restoration point. Subtransaction marked as ROLLED_BACK.
      • If the device is unreachable: Configuration may or may not have changed depending on when connectivity was lost. Subtransaction marked as FAILED.

    • Pending devices (positioned after the failed device in the sequence): Configuration changes are not applied at all. Subtransactions marked as SKIPPED.

  4. Cleanup: Restoration points are deleted for all reachable devices in all cases (whether rollback was triggered or not).

Multi-transaction behavior

For operations involving multiple transactions (composite services, multi-service engineering rules, multi-rule engineering rules):

  • Completed transactions: All transactions that finished 100% successfully are not affected by rollback.
  • Failed transaction: When a failure occurs, the current transaction is rolled back as described above.
  • Subsequent transactions: All remaining transactions in the sequence are aborted and will not execute.

Example: If a composite service includes 3 services, and the 2nd service fails:

  • Service 1: ✅ Completed successfully → configuration remains applied
  • Service 2: ❌ Failed → rollback triggered, devices reverted
  • Service 3: ⏭️ Skipped → never executed

Workflow diagram

graph TD
    Start[Transaction starts] --> Checkpoint[Create restoration point<br/>on all devices]
    Checkpoint --> Deploy[Deploy configuration<br/>to devices in sequence]
    Deploy --> Check{Deployment<br/>result?}

    Check -->|All succeed| Success[All devices configured]
    Success --> Cleanup1[Delete restoration points]
    Cleanup1 --> End1[Transaction: SUCCESS]

    Check -->|Failure occurs| Rollback[Rollback triggered]
    Rollback --> Successful[Successful devices:<br/>Revert to checkpoint<br/>Status: ROLLED_BACK]
    Rollback --> Failed{Failed device<br/>reachable?}
    Failed -->|Yes| FailedRevert[Revert to checkpoint<br/>Status: ROLLED_BACK]
    Failed -->|No| FailedUnreach[Cannot revert<br/>Status: FAILED]
    Rollback --> Pending[Pending devices:<br/>Skip configuration<br/>Status: SKIPPED]

    Successful --> Cleanup2[Delete restoration points]
    FailedRevert --> Cleanup2
    FailedUnreach --> Cleanup2
    Pending --> Cleanup2
    Cleanup2 --> End2[Transaction: FAILED]

    End2 -.-> Multi{Part of<br/>multi-transaction?}
    Multi -->|Yes| Abort[Abort remaining<br/>transactions]
    Multi -->|No| Final[End]
    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;

Subtransaction states

When reviewing transaction logs, you'll see these states:

  • SUCCESS: Device was configured successfully and no rollback was triggered
  • ROLLED_BACK: Device was configured successfully but reverted due to a failure elsewhere
  • FAILED: Device experienced a failure and could not be reverted (usually due to unreachability)
  • SKIPPED: Device configuration was never attempted due to an earlier failure

Roadmap

We plan to make the rollback option configurable so that users may decide to rollback all transactions in a multi-transaction scenario (composite services, multi-service/multi-rule engineering rules), instead of only rolling back the failed transaction.