[lxc-devel] [PATCH] add lxc.network.script(.pre|.post|) configuration hooks

[Daniel Lezcano]

On 10/08/2010 05:13 PM, Michael Tokarev wrote:
> Stefan Tomanek wrote:
>    
>> Dies schrieb Daniel Lezcano (daniel.lezcano at free.fr):
>>
>>      
>>> Are we sure, we want to add these hooks (pre and post) ? I am not
>>> against adding them, but IMO it is more sane to add them if needed
>>> rather than adding something which may not be used.
>>>        
>> Well, until now, there was not a single hook, although I desperately
>> needed one. And there are probably people out there who might use
>> these hooks and are not able to add them for themselves.
>>
>>      
>>> Wouldn't preferable to have these two hooks:
>>>
>>>       lxc.network.script.up
>>>       lxc.network.script.down
>>>
>>> (script parameter will need 'name', 'conf section' 'up' | 'down' ...
>>>        
>> I still advise to split the hooks into generic ones and those specific
>> to the network type. The parameters passed to a script configuring a veth
>> device will be completely different than those passed to a macvlan device;
>> generic commands can then be placed in a different script, while special
>> commands can be handled in specific scripts.
>>      
> Note that the script may receive other parameters, depending on the
> type of the network device, just the first 3 are fixed.  THere's also
> $ENVIRONMENT $VARIABLES for us.
>
>    
>> I'd at least propose to use two hooks for setting up the interface, on being called
>> in instanciate_* (.up?), passing the arguments suitable to that network type, as well as
>> one generic (.post-up?)
>>      
> If there's a need, the "specific" script may call some common
> code/script by its own, or the reverse.  There's no need to do
> that in lxc.  Of if we do, how about adding a _set_ of scripts
> for each "stage" ?  :)
>
>    
>>> If there is a need for a pre or post hook, we can easily add later:
>>>        
>> Sure, _we_ probably can, but not the person who might need the patch. There are quite
>> many sysadmins who are masters at shell scripting, but are unable to add such a hook
>> to a C codebase. Not being able to extend the system in an easy fashion would be a huge
>> show stopper for them, just as the lack of scripting was to me.
>>      

I am not a sysadmin, may be you are right, having the hooks available is 
good, but I am still not convinced they are needed. I am heavily using 
kvm, and with the two scripts qemu-ifup and qemu-ifdown I am quite happy :)
Anything to be done before or after falls in /etc/network/interfaces.

> There IS a trivial way to extend system already (when
> just ONE hook is implemented) - chain your scripts.
> There's no need to re-implement shell in lxc.
>    

Michael, I am not sure I get the idea. Can you elaborate a bit ?
In our case, we need the veth name which is available in 
instanciate_veth, no ?