Smarter network_setup hooks

[Miguel Angel]

Hello everybody,
2014/1/3 Dan Kenigsberg <danken at 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
gerrit,
we pass down the actual request, plus the current network configuration,
whenever the unified_persistence is enabled.

      {"request":
           {
           "networks": {"virtnet": {"bonding" : "bond0", "bridged": true,
"vlan":27}},
           "bondings": {"bond0": {"nics":["eth1","eth2"]}},
           "options":  {"conectivityCheck":false}
           },
        "current":
           {
            "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.
>


Cheers,
Miguel Ángel Ajo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20140103/c0ad0fd8/attachment.html>