Re: RFC: virInterface change transaction API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]