[libvirt] [PATCH] network: Added hook for network modification event

[Laine Stump]

Sorry, I was offline for an extended time (the last week due to a bit of 
"political unrest" :-), and just returned yesterday...

On 07/26/2016 07:18 AM, Anton Khramov wrote:
> Hi Cole,
>
> Any news on this change?
>
> Regards,
> Anton
>
> On 07/18/2016 11:46 PM, Cole Robinson wrote:
>> On 07/13/2016 07:06 AM, Khramov Anton wrote:
>>> From: Anton Khramov <anton at endocode.com>
>>>
>>> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1181539
>>> ---
>>>   docs/hooks.html.in          | 2 ++
>>>   src/network/bridge_driver.c | 6 ++++++
>>>   src/util/virhook.c          | 3 ++-
>>>   src/util/virhook.h          | 1 +
>>>   4 files changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/docs/hooks.html.in b/docs/hooks.html.in
>>> index 1aae00c..d4f4ac3 100644
>>> --- a/docs/hooks.html.in
>>> +++ b/docs/hooks.html.in
>>> @@ -250,6 +250,8 @@
>>>             <pre>/etc/libvirt/hooks/network network_name plugged begin -</pre>
>>>           Please note, that in this case, the script is passed both network and
>>>           domain XMLs on its stdin.</li>
>>> +      <li>When network is updated, the hook script is called as:<br/>
>>> +          <pre>/etc/libvirt/hooks/network network_name updated begin -</pre></li>
>>>         <li>When the domain from previous case is shutting down, the interface
>>>           is unplugged. This leads to another script invocation:<br/>
>>>             <pre>/etc/libvirt/hooks/network network_name unplugged begin -</pre>
>>> diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
>>> index 0fd2095..61ab17b 100644
>>> --- a/src/network/bridge_driver.c
>>> +++ b/src/network/bridge_driver.c
>>> @@ -3460,6 +3460,12 @@ networkUpdate(virNetworkPtr net,
>>>               goto cleanup;
>>>           }
>>>       }
>>> +
>>> +    /* call the 'updated' network hook script */
>>> +    if (networkRunHook(network, NULL, NULL, VIR_HOOK_NETWORK_OP_UPDATED,
>>> +                       VIR_HOOK_SUBOP_BEGIN) < 0)
>>> +        goto cleanup;
>>> +
>>>       ret = 0;
>>>    cleanup:
>>>       virNetworkObjEndAPI(&network);
>>> diff --git a/src/util/virhook.c b/src/util/virhook.c
>>> index d37d6da..a8422a2 100644
>>> --- a/src/util/virhook.c
>>> +++ b/src/util/virhook.c
>>> @@ -93,7 +93,8 @@ VIR_ENUM_IMPL(virHookNetworkOp, VIR_HOOK_NETWORK_OP_LAST,
>>>                 "started",
>>>                 "stopped",
>>>                 "plugged",
>>> -              "unplugged")
>>> +              "unplugged",
>>> +              "updated")
>>>   
>>>   static int virHooksFound = -1;
>>>   
>>> diff --git a/src/util/virhook.h b/src/util/virhook.h
>>> index 550ef84..4015426 100644
>>> --- a/src/util/virhook.h
>>> +++ b/src/util/virhook.h
>>> @@ -82,6 +82,7 @@ typedef enum {
>>>       VIR_HOOK_NETWORK_OP_STOPPED,        /* network has stopped */
>>>       VIR_HOOK_NETWORK_OP_IFACE_PLUGGED,  /* an interface has been plugged into the network */
>>>       VIR_HOOK_NETWORK_OP_IFACE_UNPLUGGED,    /* an interface was unplugged from the network */
>>> +    VIR_HOOK_NETWORK_OP_UPDATED,        /* network has been updated */
>>>   
>>>       VIR_HOOK_NETWORK_OP_LAST,
>>>   } virHookNetworkOpType;
>>>
>> ACK this looks good to me. CCing laine to see if he wants to ACK when he's
>> back online, if not I'll push it in a week.

This looks okay to me too, although I momentarily wondered if the sub-op 
should be VIR_HOOK_SUBOP_END, since this is happening after the update 
is finished. But then I realized that the hook name itself is saying 
that the update has already happened (it is "UPDATED", not "UPDATE"), so 
I think that's okay (it's also the way the IFACE_PLUGGED AND 
IFACE_UNPLUGGED hooks are handled).

(When I looked back to the discussion of the previous version of the 
patch, it made me realize that a hook run when a network's firewall is 
reloaded would also be useful, but that's a separate issue (iptables 
rules are reloaded 1) when libvirtd gets a SIGHUP, 2) when libvirtd is 
restarted, or 3) when firewalld is reloaded). Anyway there really is no 
end to the places a hook could potentially be useful, so trying to get 
ahead of it is a losing proposition).

So yeah, it's fine with me to push it.