close

keyboard_arrow_left

Table of Contents Expand all

list Table of Contents

English

Time Voyager

date_range 30-May-23

arrow_backward

arrow_forward

Time Voyager Overview

When you commit a staged blueprint, thereby deploying updates to the network, you may find that the result is not what you expected. Or maybe you've committed changes to a blueprint by mistake and you want to undo those changes. Another scenario may be that 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 automatically restore previous revisions of a blueprint.

A blueprint can be jumped back to any retained revision. The five (5) most recent blueprint commits are retained. 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 retain a particular revision indefinitely by keeping it. When you keep a revision it is not included in the five revisions that cycle out. You can keep up to twenty-five (25) revisions, effectively having thirty (30) blueprint revisions to choose from. 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 you can 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. When jumping to a revision, 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 have not been committed are discarded. If this is an issue, do not jump 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. It is important to do a detailed review of changes before committing a rollback. Therefore 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 cannot 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 jump 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, you must 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.

Jump to Previous Blueprint Revision

Note:

When you rollback to a previous revision, any previously staged changes that have not been committed are discarded. If this is an issue, do not jump to a different revision until you've committed the uncommitted changes.

From the blueprint, click Time Voyager, then click the Jump to this revision button for the revision to jump to (first of four buttons in Actions section).
Any uncommitted changes in the staged area are discarded. If this is an issue, close the dialog and address the uncommitted changes before proceeding. To proceed, click Rollback.
You can make additional changes to the blueprint before committing. For example, if you've replaced a device, the device ID (serial number) will change, but the IP won't. You can create the device agent and update the serial number in your blueprint before committing the revision change.
Click Uncommitted, then click the diff tabs to review the changes.
If you decide that you don't want to jump to this revision, click the Revert button to discard the changes.
To proceed, click the Commit button (top-right) to see the dialog for committing changes and creating a revision.
We recommend that you enter the optional revision description to identify the changes. Specific differences between revisions are not displayed, so the description is the only change information available for the revision.
Click Commit to commit your changes to the active blueprint and create a revision. In some cased, you might also need to reset resource group overrides.
If you click Time Voyager you'll see the revision as the current one.

Keep Saved Blueprint Revision

From the blueprint, click Time Voyager, then click the Keep this revision button for the revision to keep (second of four buttons in Actions section).
Click Save to confirm and proceed. The button turns gray indicating that the revision has been saved indefinitely. It won't be deleted until you manually delete it.

Update Blueprint Revision Description

From the blueprint, click Time Voyager, then click the Update description button for the revision to keep (third of four buttons in Actions section.)
Enter or change the description.
Click Update to change the description and return to the table view.

Delete Kept Blueprint Revision

From the blueprint, click Time Voyager, then click the Delete button for the revision to delete (fourth of four buttons in Actions section). You can't delete a revision if there are five (5) or fewer of them in the list.
Click Delete to delete the revision and return to the table view.

arrow_backward PREVIOUS Commit Blueprint

NEXT arrow_forward Analytics

Juniper Apstra 4.1.2 / 4.1.1 / 4.1.0 User Guide

ON THIS PAGE