[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCHv2 1/7] interface: new public API for networkconfig change transactions

On 05/19/2011 06:15 PM, Christian Benvenuti (benve) wrote:
-----Original Message-----
From: libvir-list-bounces redhat com [mailto:libvir-list-
bounces redhat com] On Behalf Of Laine Stump
Sent: Thursday, May 19, 2011 1:51 PM
To: libvir-list redhat com
Subject: [libvirt] [PATCHv2 1/7] interface: new public API for
networkconfig change transactions

From: Michal Privoznik<mprivozn redhat com>

This is the API agreed on in:


(with a slight name change to use "...begin" rather than
"...start"). This implements transactional changes to the host network
config. When a transaction is begun with ncf_change_begin(), all other
netcf APIs will continue to work as they always have, but a snapshot
of the existing config will be taken, allowing reversion (rollback,
using ncf_change_rollback()) to the exact state of config at the time
ncf_change_begin() was called. Alternately, if it's determined that
the new changes are acceptable, ncf_change_commit() can be called,
which will eliminate the snapshot and make the changes permanent.

As a failsafe measure, if neither ncf_change_commit() or
ncf_change_rollback() is called by the next time the system reboots,
the netcf-transaction initscript will be automatically called to
rollback the changes.
Why do you think the default rollback (post reboot, for non-committed
transactions) is a good default?

It is intended as a failsafe device when the host becomes unstable, and this is the safest default behavior. If someone has gone to the trouble of beginning a transaction, that implies that they are nervous enough about the outcome of the changes that they think they might need to be reverted. And it also implies that they will be monitoring the changes and have ample opportunity to commit the transaction prior to the system rebooting.

When/where is that automatic rollback enforced?

It's done at boot time in an initscript that will be installed by netcf. See:


(I could not find it in the patches).

Almost all the functionality lives in the netcf library. the libvirt API just provides a simple pass-through to that functionality.

  Does it trigger a log message too?

Ah - that's a good point! the initscript should log a message indicating that it is restoring something rather than just silently doing it. I'll make sure to squash that in before pushing the initscript to netcf.

Do you think it may make sense to have that default behavior controlled
by a (global, ie, not per-interface) parameter?

So far you're the first person to ask for that. There's nothing in the API that would prevent us from adding it in, but my current inclination is to get this pushed with the current functionality so people can start using it.

I am not suggesting the introduction of such parameter (but I would not
be against it), but I would suggest a 4th virsh command to list at
least the interfaces with a pending (ie, not committed yet) transaction.

Another interesting idea, but something that, as we don't currently have a specific need for it, can be done at a later time.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]