Smarter network_setup hooks

[Adam Litke]

On 03/01/14 12:20 +0000, Dan Kenigsberg wrote:
>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!

Seems like a logical thing to do.  What specific mechanism do you
suggest for passing the JSON strings to the hook script?  If passed as
arguments to the hook script we would need to consider shell escaping
and argv length restrictions.

What about writing these out to a special file and adding a new
getContext() call to the hooking module.  A script that is unconcerned
with the context would not require any changes.  But a script that
wants access would simply do:

    ctx = hooking.getContext()

and ctx would be the contents of the special file already decoded into
a native Python object for easy consumption.  This could easily be
extended to any hook which may want to provide some context to
implementors.

One more question comes to mind:  Are there any pieces of information
that we would need to redact from the context (passwords or other
sensitive information)?