On Mon, Apr 18, 2011 at 12:25:21PM -0400, Laine Stump wrote: > On 04/14/2011 09:03 AM, Dan Kenigsberg wrote: > >>3) initscript > >> > >> This initscript will at first live in (be installed by) netcf > >> (called /etc/init.d/networking-config?), but hopefully it will > >> eventually be accepted by the initscripts package (which includes > >> the networking-related initscripts), as it is of general use. (Dan > >> Kenigsberg already already took a stab at this script last year, > >> but received no reply from the initscripts maintainers, implying > >> they may not be too keen on the idea right now - it might take some > >> convincing ;-) > >> > >>https://fedorahosted.org/pipermail/initscripts-devel/2010-February/000025.html > >> > >> It will have three commands, one of which will be called > >> automatically by "start" (the command called automatically at boot > >> time): > >> > >> snapshot_config > >> > >> This will save a copy of (what the script believes are - is this > >> problematic?) all network-config related files. It may or may not > >> be called by netcf (see the notes in ncf_start_change() above. > >> > >> If this function finds that a snapshot has already been taken, > >> it should fail. > >> > >> > >> rollback_config (automatically called from "start" at boottime) > >> > >> This will move back (from the saved copies) all files that were > >> changed/removed since snapshot, *and delete any files that have > >> been added*. > >> > >> Note that this command doesn't need to worry about ifup/ifdown, > >> because it will be called prior to any other networking startup > >> (part of the reason that netcf will need to deal with that). > >> > >> I notice that Dan K's version saves the modified files to a > >> "rollback-${date}" directory. Does this seem like a good idea? > >> It's nice to not lose anything, but there is no provision for > >> eliminating old versions, so it could grow without bound. > >I sleep better at night when there are backups... Obviously, I should not have > >kept them beyond a certain limit (last 20). And I'd understand if you think that > >it is the business of a backup system, or conf management system, to take theses > >backups. > > > I'm agnostic. Anyone else have an opinion? Does there need to be a > method in the API to get to these backups? Or are they just there > for manual intervention in the case of a catastrophe? I think we're getting into overkill myself. Best to concentrate of getting the basic functionality present & working. If someone decides we need to extend this work to handle historical snapshots of the interface config we can deal with it later. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list