Hello everybody,
2014/1/3 Dan Kenigsberg <dan...@redhat.com>

> 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.

Dan, thank you for starting this thread,

> [...]

> 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.

Yes, going the xml way was the first approach, but then we realized
that the cost of maintaining a new xml schema probably wasn't worth.

> 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.

In the last patch set I've extended it a little bit with suggestions in
we pass down the actual request, plus the current network configuration,
whenever the unified_persistence is enabled.

           "networks": {"virtnet": {"bonding" : "bond0", "bridged": true,
           "bondings": {"bond0": {"nics":["eth1","eth2"]}},
           "options":  {"conectivityCheck":false}
            "networks": {"ovirtmgmt": {"nic" : "eth0", "vlan":27 }}
            "bondings": {"bond1": {"nics":["eth3","eth4"]}}

> 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!
My opinion the same as yours, but I'm new to this project,

If the chances for this API parameters to change are low:
In the event of that significant changes happening, we could mitigate the
problem introducing an intermediate layer to dump/load the information
from the API parameters.

I'd really like to know what do others think about this.

> Dan.

Miguel Ángel Ajo.
vdsm-devel mailing list

Reply via email to