You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Junos (and to a lesser extent IOS-XR), the following functionality is available:
the last N commits are retained with the date and time they were made
commits can have comments
it is easy to diff between two previous commits
it is easy to roll back N commits
We should be able to add all of this functionality.
Details
We can keep the files in a designated folder named by date/time. Settings for this (like how many commits are kept) can go in the main config file.
We need to store both the generated files and the config file. Rationale follows.
On one hand, the generated files are the "actual" config as executed by the system, so rolling back would be guaranteed to be the same. Theoretically, rolling back just the config file and then regenerating the generated files should be the same, but the tool might produce a different output from the same config file now. On the other hand, if we roll back only the generated files, we'd have to manually change the config file to match, or it would just get overwritten on the next regen.
If we keep both, we should prompt the user something to the effect of "this config produces a different output than it did at the time this snapshot was generated. here are the differences between the previous config and what it would be now. would you like to apply the new version, or the snapshot version?" This question should be asked before the rollback is actually executed.
Feature description
In Junos (and to a lesser extent IOS-XR), the following functionality is available:
We should be able to add all of this functionality.
Details
We can keep the files in a designated folder named by date/time. Settings for this (like how many commits are kept) can go in the main config file.
We need to store both the generated files and the config file. Rationale follows.
On one hand, the generated files are the "actual" config as executed by the system, so rolling back would be guaranteed to be the same. Theoretically, rolling back just the config file and then regenerating the generated files should be the same, but the tool might produce a different output from the same config file now. On the other hand, if we roll back only the generated files, we'd have to manually change the config file to match, or it would just get overwritten on the next regen.
If we keep both, we should prompt the user something to the effect of "this config produces a different output than it did at the time this snapshot was generated. here are the differences between the previous config and what it would be now. would you like to apply the new version, or the snapshot version?" This question should be asked before the rollback is actually executed.
Other
This is blocked by #43.
The text was updated successfully, but these errors were encountered: