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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list