On 04/19/2011 10:59 AM, Dan Kenigsberg wrote:
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:
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.
What about the rollback that takes place at boot time if the changes
haven't been committed? Should that *always* happen, or should it be
controllable by flags as well. I had intended that at least that
automatic rollback would be present in the first implementation...
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list