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 :|