On 05/10/2011 09:52 AM, Laine Stump wrote:
> I think we also need to add comments to
>
> virInterfaceDefineXML
> virInterfaceUndefine
> virInterfaceCreate
> virInterfaceDestroy
>
> about the difference in their behaviour if a transaction is open, vs
> normal non-transactional usage.
They will behave the same at the moment they are called, but it will be
possible to later undo what was done, because "opening the transaction"
is really just saving off the original config state.
More importantly (and probably this is the part you were talking about)
if virInterfaceChangeCommit() isn't called before the next time the
system is rebooted, all the changes will be automatically reverted
during the boot process.
(I want to make sure that nobody thinks opening a transaction means that
all the changes are saved into a staging area and then later committed
to the live config all at once when the transaction is committed - doing
it this way would eliminate the ability to test the new config prior to
committing).
But suppose that the changes being made are such that I'm swapping
connectivity from one interface to another during the course of the
changes. If I make the changes live, then there is a window where
either both interfaces are connected, or where neither interface is
connected, and both scenarios have implications on how I connect to
issue the remainder of the commands needed to commit to the change.
Maybe it is worth _also_ having the ability to queue up several changes,
and apply them all at once, so that a single interface can queue up all
the proposed changes and finally try out the batch, and the second
interface then commits if all went well, rather than having to
coordinate the handoff of half the changes being made by interface 1 and
the other half by interface 2.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org