[libvirt] RFC: virInterface change transaction API

[Dave Allan]

On Tue, Apr 19, 2011 at 03:35:10PM -0400, Laine Stump wrote:
> 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...

Somewhat related, I think the definition of and test for a successful
configuration should be left to the application developer.  We could
provide some prepackaged tests, e.g., ping some host, connect to some
host on some port, but I think the definition of working connectivity
can be subtle, and I don't think we should impose one definition, or
even a set of definitions, on all applications.

Dave