<div dir="ltr"><div class="gmail_extra">Hi Assaf, Thank you very much for the summary,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Just a few questions, there are things I don't understand yet:</div>
<div class="gmail_extra"><br><div class="gmail_quote">2014/1/8 Assaf Muller <span dir="ltr"><<a href="mailto:amuller@redhat.com" target="_blank">amuller@redhat.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Mid-thread summary:<br>
<br>
First some terminology so we're all on the same page:<br>
'request' - The setupNetworks that just arrived<br>
'running config' - If unified persistence is being used - All networking on the host as VDSM sees it<br>
'expected' - If unified persistence is being used - The running config after the effects of the request, but before the hook is ran<br>
<br></blockquote><div><br></div><div>correct</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think we all agree that we have to expose the 'request' to the hook.<br>
However, there's two different approaches:<br>
1) Allow the hook to rewrite parts of the request (For example, if two networks were sent, and the hook handled one of them, it could<br>
then delete that network from the request, so VDSM will only continue to configure the 2nd network).<br></blockquote><div><br></div><div>In this case ,if the hook deleted the "2nd network", VDSM couldn't handle the network config persistence anymore, right?,</div>
<div><br></div><div>I didn't expect this use case, I only expected tweaks, etc (before or after network setup), for example, setting special hardware</div><div>capabilities using ethtool or those kind of things.</div>
<div> <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Toni's idea with marking devices as hook-configured. So if a network is over a bridge over a VLAN over a bond over three NICs, hooks<br>
could configure only the NICs (For example) and VDSM would configure the rest, whereas the first idea means that the hook would<br>
have to configure the entire network (Bridge, VLANs, bonds, and all 3 NICs) and then remove that network from the request.<br>
The disadvantage of this method is that it would be harder to implement, and have references to the hooks flag throughout all of VDSM.<br>
<br></blockquote><div><br></div><div>You mean that if the hook marked a certain device as "hook handled" then, VDSM would just keep this information along with</div><div>the network config, etc... and won't do any setup, just config-keeping, right?</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Then there's the matter of IF to expose the 'running config' and 'expected'.<br>
<br>
My main argument is that it's very easy to expose to the hooks (But then why not expose other 'random' data that is easy for VDSM to calculate?),<br>
and that we don't understand all usages for the setupNetworks hooks. I'd rather we expose too much information than not enough and screw<br>
over hook writers.<br>
<br></blockquote><div><br></div><div>We have something important here, the hooks don't need to be python-written, they could be bash scripts, or any other thing... </div><div>that means that they wouldn't have access to get "running config", but they could calculate "expected".</div>
<div><br></div><div>So, my vote here goes for "request" + "running config".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Either way, let's get some votes in a timely manner so we could manage to implement this for 3.4.<br>
<div class="im HOEnZb"><br></div></blockquote><div><br></div><div>Thanks Assaf! ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">
<br>
Assaf Muller, Cloud Networking Engineer<br>
Red Hat<br>
<br>
</div><div class="im HOEnZb">----- Original Message -----<br>
From: "Adam Litke" <<a href="mailto:alitke@redhat.com">alitke@redhat.com</a>><br>
To: "Miguel Angel" <<a href="mailto:miguelangel@ajo.es">miguelangel@ajo.es</a>><br>
Cc: <a href="mailto:dsulliva@redhat.com">dsulliva@redhat.com</a>, <a href="mailto:arch@ovirt.org">arch@ovirt.org</a>, <a href="mailto:vdsm-devel@fedorahosted.org">vdsm-devel@fedorahosted.org</a><br>
</div><div class="im HOEnZb">Sent: Monday, January 6, 2014 3:32:07 PM<br>
Subject: Re: [vdsm] Smarter network_setup hooks<br>
<br>
</div><div class="HOEnZb"><div class="h5">On 04/01/14 20:08 +0100, Miguel Angel wrote:<br>
>Hi Adam<br>
><br>
>Thanks for the feedback<br>
><br>
>2014/1/3 Adam Litke <<a href="mailto:alitke@redhat.com">alitke@redhat.com</a>><br>
><br>
>> On 03/01/14 12:20 +0000, Dan Kenigsberg wrote:<br>
>><br>
>>> 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>
>>> [....]<br>
>><br>
>> Seems like a logical thing to do. What specific mechanism do you<br>
>> suggest for passing the JSON strings to the hook script? If passed as<br>
>> arguments to the hook script we would need to consider shell escaping<br>
>> and argv length restrictions.<br>
>><br>
>> As for the libvirt domain xml we pass to other hooks, we write a temporary<br>
>file<br>
>and we set an environment variable pointing to it before calling the script<br>
><br>
><br>
>> What about writing these out to a special file and adding a new<br>
>> getContext() call to the hooking module. A script that is unconcerned<br>
>> with the context would not require any changes. But a script that<br>
>> wants access would simply do:<br>
>><br>
>> ctx = hooking.getContext()<br>
>><br>
>> and ctx would be the contents of the special file already decoded into<br>
>> a native Python object for easy consumption. This could easily be<br>
>> extended to any hook which may want to provide some context to<br>
>> implementors.<br>
>><br>
><br>
>That would be nice, so scripts written in python wouldn't need to look for,<br>
>and parse<br>
>the file.<br>
><br>
>This is an example of a simple hook:<br>
><br>
><a href="http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py" target="_blank">http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py</a> (look<br>
>inside the ValidatesHook decorator)<br>
><br>
><br>
>It'd be quite simplified. We would also need a "setContext()..." to update<br>
>context with changes.<br>
<br>
Yeah seems reasonable. Then hook scripts can become much simpler and<br>
easier to read and write:<br>
<br>
ctx = hooking.getContext()<br>
ctx['foo'] = 'bar'<br>
hooking.setContext(ctx)<br>
<br>
><br>
><br>
>><br>
>> One more question comes to mind: Are there any pieces of information<br>
>> that we would need to redact from the context (passwords or other<br>
>> sensitive information)?<br>
>><br>
>><br>
>I think there is no sensitive information as far as I know.<br>
><br>
>Greetings,<br>
>Miguel Ángel.<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
vdsm-devel mailing list<br>
<a href="mailto:vdsm-devel@lists.fedorahosted.org">vdsm-devel@lists.fedorahosted.org</a><br>
<a href="https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel</a><br>
</div></div></blockquote></div><br></div></div>