Smarter network_setup hooks

[Dan Kenigsberg]

Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the
implementation of setupNetworks in Vdsm: two hook points where added:
before and after the setupNetworks verb takes place.

This is useful because sometimes, Vdsm's configuration is not good
enough for the user. For example, someone may need to set various
ETHTOOL_OPTS on a nic. Now, they can put a script under
/usr/libexec/vdsm/after_network_setup/ that tweak their ifcfg-eth*
files after they have been written by Vdsm.

However, the hook script only knows that *a* change of network
configuration took place. It does not know which change took place, and
has to figure this out on its own.

Enters http://gerrit.ovirt.org/20330 "allow hooks to pass down
dictionaries in json format".

I'd like to discuss it here, as it introduces a new Vdsm/Hook API that
is quite different than what we have for other hooks. Unlike with Vm
and VmDevice creation, where Vdsm uses libvirt's xml definition
internally as well as to communicate with the hooks,
before/after_network_setup have to define their own means of
communication.

I would like to suggest to use the same information passed on the
Engine/Vdsm API, and extend its reach into the hook script. The three
arguments to setupNetworks(networks, bondings, options) would be dumped
as json strings, to be read by the hook script.

This option is very simple to use and implement, it gives the hook all
the information that Vdsm-proper has, and allows for greatest
flexibility for hook writers. This is also the down side of this idea:
hook script may do all kinds of things with this information, some of
them unsupportable, and they should be notified when Engine/Vdsm API
changes.

In my opinion, it is a small price to pay: hooks have always had the
China Store Rule - if you break something, you own it. Hook users must
know what they're doing, and take care not to use deprecated bits of the
API.

What is your opinion? Comments and suggestions are most welcome!

Dan.