<div dir="ltr"><br><div class="gmail_extra">Hello everybody,<br><div class="gmail_quote">2014/1/3 Dan Kenigsberg <span dir="ltr"><<a href="mailto:danken@redhat.com" target="_blank">danken@redhat.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Recently, Miguel Angel Ajo (CCed) has added a nice functionality to the<br>
implementation of setupNetworks in Vdsm: two hook points where added:<br>
before and after the setupNetworks verb takes place.<br></blockquote><div><br><br><div class="gmail_extra">Dan, thank you for starting this thread, <br></div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[...]<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'd like to discuss it here, as it introduces a new Vdsm/Hook API that<br>
is quite different than what we have for other hooks. Unlike with Vm<br>
and VmDevice creation, where Vdsm uses libvirt's xml definition<br>
internally as well as to communicate with the hooks,<br>
before/after_network_setup have to define their own means of<br>
communication.<br></blockquote><div><br></div><div>Yes, going the xml way was the first approach, but then we realized<br>that the cost of maintaining a new xml schema probably wasn't worth.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I would like to suggest to use the same information passed on the<br>
Engine/Vdsm API, and extend its reach into the hook script. The three<br>
arguments to setupNetworks(networks, bondings, options) would be dumped<br>
as json strings, to be read by the hook script.<br></blockquote><div><br><br></div><div>In the last patch set I've extended it a little bit with suggestions in gerrit, <br>we pass down the actual request, plus the current network configuration,<br>
</div><div>whenever the unified_persistence is enabled.<br></div><div><br> {"request":<br> {<br> "networks": {"virtnet": {"bonding" : "bond0", "bridged": true, "vlan":27}},<br>
"bondings": {"bond0": {"nics":["eth1","eth2"]}},<br> "options": {"conectivityCheck":false}<br> },<br> "current":<br>
{<br> "networks": {"ovirtmgmt": {"nic" : "eth0", "vlan":27 }}<br> "bondings": {"bond1": {"nics":["eth3","eth4"]}}<br>
}<br> }<br><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
This option is very simple to use and implement, it gives the hook all<br>
the information that Vdsm-proper has, and allows for greatest<br>
flexibility for hook writers. This is also the down side of this idea:<br>
hook script may do all kinds of things with this information, some of<br>
them unsupportable, and they should be notified when Engine/Vdsm API<br>
changes.<br>
<br>
In my opinion, it is a small price to pay: hooks have always had the<br>
China Store Rule - if you break something, you own it. Hook users must<br>
know what they're doing, and take care not to use deprecated bits of the<br>
API.<br>
<br>
What is your opinion? Comments and suggestions are most welcome!<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>My opinion the same as yours, but I'm new to this project, <br><br>If the chances for this API parameters to change are low:<br>
</div><div>In the event of that significant changes happening, we could mitigate the <br>problem introducing an intermediate layer to dump/load the information<br>from the API parameters.<br><br>I'd really like to know what do others think about this. <br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><font color="#888888">
Dan.<br>
</font></span></blockquote></div><br><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Miguel Ángel Ajo.<br><br></div></div>