Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Time Voyager Introduction

When you commit a staged blueprint (deploy updates to the network), the result might not be what you expected. Maybe you've committed changes to a blueprint by mistake and you want to undo those changes. Or maybe you've decided to return the network to the state it was in several revisions ago. Depending on the level of complexity, manually staging and committing changes to undo what you've done can be difficult and error-prone. In these cases you'll want to use Time Voyager to quickly restore previous revisions of a blueprint.

You can roll back a blueprint to any retained revision. The 5 most recent blueprint commits are retained, by default. When you commit a sixth time, the first revision is discarded, and the sixth revision becomes the fifth, the second revision becomes the first, and so on as additional blueprint changes are committed. You can change the number of automatically saved revisions to up to 100 revisions. In the Commit dialog, a message lets you know that if you've reached your limit and you commit another change, the new revision will replace the oldest auto-saved revision. If you've reached the limit when you want to commit, and you don't want any revisions deleted, you can close the commit dialog without committing, then increase the number of auto-saved revisions in Time Voyager.

You can retain a particular revision indefinitely by keeping it, or manually saving it. When you keep a revision it is not included in the 5 revisions that cycle out. You can keep up to 25 revisions, effectively having 30 blueprint revisions to choose from, by default. (If you change the number of automatically saved revisions to the maximum of 100, you could save up to 125 revisions.) Keep in mind that each revision requires storage space. If you decide that you no longer want to keep a revision you can simply delete it.

When committing a blueprint we recommend that you add a revision description to help identify the changes made in that revision. These descriptions are displayed in the revision history section of the blueprint as long as that revision is retained. If you don't add a description when you commit you can always add one later (but you'll need to remember what the changes were). When jumping to a revision (rolling back), this description helps you choose the correct one. Specific differences between revisions are not displayed, so the description is the only change information available for that revision.

When jumping to a revision, any previously staged changes that haven't been committed are discarded. If this is an issue, do not roll back until you've addressed the uncommitted changes.

Time Voyager is not just an UNDO function. When using Time Voyager you roll back to a previous commit. This means that anything deleted on the last commit is re-applied when rolling back. There can be many changes in-between revisions, both additions and removals, all of which would be included in the rollback. Before committing a rollback, it's important that you review the pending changes in detail. Time Voyager is better compared with a Revision Control System (for the whole network!) than an UNDO function.

Unsupported Time Voyager Scenarios

  • After you've upgraded Apstra server, you can't jump to a blueprint with an older version because the blueprint revision history is discarded on upgrade. If you need to return to a previous Apstra version that was taken prior to upgrading Apstra, refer to Restore Database. This method could cause issues from a device config standpoint.
  • It's not supported when the Pristine config has changed between revisions.
  • It's not supported when the NOS versions are different between revisions. You could downgrade the NOS version to the same version using the device manager, then roll back to a previous revision.
  • Devices that were allocated in a previous revision that are no longer available result in the build error system ID does not exist. (Conversely, adding a device and jumping to a previous revision without that device will be successful. The added device will be removed.)
  • Resources that were assigned in a previous revision that have been reassigned cause the build error resource already in use. To resolve the build error, manually assign resources to each member in that group or reset the resource group overrides. (Jumping to a previous revision after a previously assigned global resource pool is modified may be successful, but it could cause an intent violation.)
  • It's not supported if manual device config changes have been accepted.
  • It's not supported in any other cases where the resulting device config state is different.
Note:

Why not use Apstra server backup/restore to jump to a previous revision? Time Voyager maintains synchronized configuration between the Apstra server and devices (as much as possible); Apstra backup/restore does not. Effectively, the Apstra backup/restore is an out-of-band change from a device configuration standpoint. If a backup is restored, you would need to push a full config to make sure the device configuration reflects what you restored from the database backup. This would most likely be disruptive.

From the blueprint, click Time Voyager to go to the retained blueprint revisions. The first revision in the list is the active one. Successive revisions are ordered by date from most recent to oldest.