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

Re: [libvirt] RFC: virInterface change transaction API



On Mon, Apr 18, 2011 at 05:53:05PM +0100, Daniel P. Berrange wrote:
> On Thu, Apr 14, 2011 at 04:03:03PM +0300, Dan Kenigsberg wrote:
> > On Fri, Apr 08, 2011 at 03:31:05PM -0400, Laine Stump wrote:
> > > I've been asked to implement what some people have termed as a
> > > "transaction-oriented" API for host interface configuration (ie
> > > virInterface*()).
> > > The basic intent is to allow rollback to a known-good config if
> > > anything goes
> > > wrong when changing around the host network config with virInterface*()
> > > functions.
> > > 
> > > The most straightforward way to achieve this is that prior to calling
> > > virInterfaceDefine/virInterfaceUndefine, the current state of the
> > > host's network configuration (ie the /etc/sysconfig/network-scripts/ifcfg-*
> > > files in the case of Fedora and RHEL) would be saved off somewhere, and
> > > kept around until we're sure the new config is good; once we know that,
> > > we can just eliminate the backup. If, however, the user of virInterface*()
> > > explicitly requests, we could copy the files back; alternately if the system
> > > is rebooted without these known-good files being erased, we would assume
> > > that something went wrong and restore the original config.
> > > 
> > > As with all other virInterface functions, the details of all this will
> > > be handled by netcf (and below), but since libvirt is the main consumer
> > > of netcf, I figure this is the appropriate place to discuss how it
> > > gets done,
> > > so please let me know any opinions on any piece of this. I plan to start
> > > the implementation "soon", as I want to be finished before the end of
> > > May.
> > 
> > I like the idea, and think that virtInterface* users will benefit from it.
> > Few comments are inline.
> > 
> > > 
> > > I see 3 layers to this:
> > > 
> > > 1) libvirt
> > > 
> > >    At the libvirt layer, this feature just requires 3 new APIs, which
> > >    are directly passed through to netcf:
> > > 
> > >        virInterfaceChangeStart(virConnectPtr conn, unsigned int flags);
> > >        virInterfaceChangeCommit(virConnectPtr conn, unsigned int flags);
> > >        virInterfaceChangeRollback(virConnectPtr conn, unsigned int flags);
> > > 
> > >    For the initial implementation, these will be simple passthroughs
> > >    to similarly named netcf functions. (in the future, it would be
> > >    useful for the server side of libvirt to determine if client<->server
> > >    connectivity was lost due to the network changes, and automatically
> > >    tell netcf to do a rollback).
> > 
> > When such a feature is added, we should make it dependent on FLAG_AUTO_ROLLBACK
> > passed to ChangeStart. Higher levels on the management stack may want full
> > controll over when rollback happens.
> 
> I don't think a AUTO_ROLLBACK flag is sufficient. You'd almost certainly
> want to pass some info such as hostname/port number to test, and perhaps
> a test timeout in milliseconds, and perhaps a retry count.

Yes, that's why I wanted complete control over auto rollback, when it is
inroduced.

> I suggest a
> separate API that is invoked just after starting the TXN, to provide
> auto-rollback data.
> 
> 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 :|


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