Snapshots are a feature dear to my heart, and I've been trying to get my GNS3 WorkBench labs converted to v1 format so that we can put something under http://members.gns3.net/labs/

However, the WorkBench exercises are built around Snapshots. So until V1 has Snapshots, I'm at a standstill.

But it has lead me to think about how I think Snapshots should be implemented in GNS3v1

I think the simplest way is to draw what I see should be the directory structure when a snapshot is taken. For the following, assume that I have taken a snapshot called 0 Initial Configuration in my project called Demonstration Lab, which consists of a single router with two PCs The snapshot was taken on 2014-09-27 at 08:51:21

.[projects directory]
|-Demonstration Lab/
|---Demonstration Lab.gns3
|---Demonstration Lab-files/
|-----dynamips/
|-------configs/
|-----vpcs/
|-------pc-1/
|-------pc-2/
|---snapshots/ #Note1
|-----0 Initial Config_140927_085121/ #Note2
|-------Demonstration Lab.gns3 #Note3
|-------Demonstration Lab-files/
|---------dynamips/
|-----------configs/
|---------vpcs/
|-----------pc-1/
|-----------pc-2/


#Note1: the snapshots directory is under the Demonstration Lab directory
#Note2: The directory name for the snapshot is much shorter than the old GNS3, but still holds all the important information - I found at times that with directory names like:
topology_0 Initial Config_snapshot_270914_085121
with a bunch of directories under it would sometimes give errors on Windows PCs because the filepaths could get too long
#Note3: The snapshot contains exactly the same structure as under the Demonstration Lab directory, apart from the snapshots directory

I thinks that pretty well says it all - I don't see any need to make any other changes to the way it used to work, apart from perhaps in the Manage snapshots dialogue, it would be nice to be able to double-click on a snapshot and assume that you meant [Restore]

_________________
RedNectar
http://rednectar.net
@rednectarchris
GNS3 WorkBench-a VMware image of Ubuntu with GNS3 and VPCS installed and a collection of exercises/labs

I'm curious as to what's your opinion on leveraging Git for snapshots instead of (re)making a separate system.

@boen_robot

I can see that a version control system for GNS3 could appeal to some people. However, I think version control serves a different function than snapshots.

I do some work with VMware and various disk arrays. In the parlance of storage systems and of VMware, when you restore a snapshot, it replaces the original. Simple and expected.

I'm not a programmer (any more) but my (possibly flawed) understanding of a version control system is that it doesn't work like that. It is more like an auditing system - if you "restore" an old version, it actually modifies the current version to look like the old version - and you can quickly end up with lots and lots of versions if you say try to restart an exercise from scratch four or five times. And more confusion too.

So for a developer trying to work out a complex set of configurations for a particular topology, a version control system may be useful. And if it were to be truly mimic your real-world install, then it could also be useful there.

But I don't believe the vast majority of GNS3 users need or want that.

I believe the vast majority of GNS3 users are using GNS3 for study or learning purposes [Stephen may be able to back this up with data from the surveys that have been done]

And for people studying or learning from labs such as GNS3 WorkBench, the existing snapshot system (which took three years to refine and get to the stage where it is now starting in about sept 2010 and finally working in 0.8.6 based on topic6581.html) probably works better than a version control system. It allows a user to restore a snapshot at the start of a lab exercise, and if they want to, they can start the lab again by restoring the same snapshot. A lab can be created that has many different snapshots to restore, each presenting a variation of the same problem, and even a snapshot that loads the solution. None of this kind of activity does suits a version control system.

So in conclusion, I think the Snapshot system should be implemented as I described above, based on the behaviour of the existing (v0.8.7) system. I don't have an objection to adding a version control system to GNS3 sometime in the future, but let's not compromise the Snapshot system to do it.

_________________
RedNectar
http://rednectar.net
@rednectarchris
GNS3 WorkBench-a VMware image of Ubuntu with GNS3 and VPCS installed and a collection of exercises/labs

I don't know about Mercurial and other "changeset" systems, but "snapshot" systems like Git, AFAIK, don't do that. They store entire files upon commit, so when you restore a version from an uncommitted one, they remove the uncommitted files, and copy the repository files into the tree, thus preserving not just the original file, but also its meta data (if that's what you're worried about when you say "modifies the current version to look like the old version").

However, IF there are any commits between the current version and the one you're restoring to, then you're right - the revisions between the restored one and the current one will be kept, and a separate commit will be added on top. The files are still the same (not saved a second time), but the revision logs show them having appeared once more.

But that last characteristic is precisely the solution to what I perceive as a "problem" of the snapshot system in 0.8.7. Then again...

... I'm mostly in the minority of GNS3 users there. I mean, I have recently used GNS3 for training, but as a teacher, not as a student. On most days, I'm trying to mimic real world topologies and try out new approaches instead of risking my real world network.



I hear you though... And Git has a solution for that too, although I'll admit it may seem to make things "harder", since it will require a little additional GUI from GNS3. It's called "branches". A Git repository can have multiple branches, and revision logs show only the history of the current branch, so...

Once you reach a certain point that you know you'll be restoring to multiple times (e.g. the start of an exercise), you can create a new branch out of that commit, and switch to it. Further commits will be saved on that new branch. When you want to restart the exercise, you can just create a new branch out of the ORIGINAL branch again. Branches can be deleted, so if you want to remove traces of your past attempts/variations, you just remove the branch, leaving just the original one.

You could theoretically even create branches that are not based on any particular commit, and copy files from another revision into them, thus removing the entire history up to this point. I say "theoretically", because doing that is a little more complicated than a simple Git command (you first copy the files outside of the repository, create the empty branch, move them back into the new branch, commit), but it's doable non the less.

Whatever Snapshot solution is delivered I believe it MUST

1. Be as simple to use as the existing system
2. Provide the same functionality as the existing system
3. Be able to work WITHOUT internet connectivity (I have at least two customers who have their GNS3 labs isolated from internet access. I suspect there are more)

I'm yet to be convinced that we could provide all the above using git. But as I said, that's not to say we SHOULDN'T have a version control system. Just call it something else other than Snapshots

_________________
RedNectar
http://rednectar.net
@rednectarchris
GNS3 WorkBench-a VMware image of Ubuntu with GNS3 and VPCS installed and a collection of exercises/labs

Git satisfies C. Also B, but with the not removing newer commits exception.

Having that feature, while still satisfying A can be done with some cleverness in the GUI around it.

I think the simplest way to keep things as simple as before, while still allowing the optional preservation of newer commits is to just add one (just one!) more button or checkbox, or... anything... That tells GNS3 whether to keep commits newer than the point being restored.
(For everything else, there's 1:1 mapping between Git and 0.8.7's functionality, so it should be relatively easy to recreate the GUI in 1.0.0, in that there's no need for the GUI to be clever about Git)

If newer commits are to be kept, just revert to the particular commit, without doing anything special (as Git would do on its own).

If they're supposed to be removed, behind the scenes, GNS3 could create a new temporary branch out of the commit being restored to, switch to it, remove the original branch, and finally rename the temporary branch to the original branch's name.

There you go! Same functionality as before, with just one additional option that basically tells GNS3 whether to keep the newer commits (like I want it) vs. not keeping them (like you want it; I don't think most people care either way).




BTW,

@grossmj

Take a look at this if you haven't already ;)

(I mean, it's definitely a neater option that working with the command line...)

Hi,

I like the simplicity of the snapshot system of v0.8.7. I am sure I could use git for the snapshots in GNS3v1 but I am not yet comfortable with the tech/libs to have this implemented quickly. I think I will implement the simple system (without git) for 1.0 and have something to easily upgrade to a system that use git.

Thanks for all the comments! :)

_________________
Jeremy, GNS3 Programmer & Benevolent Dictator for Life.