Whichever way we decide to do this, I think the important bit is documentation 
- We have
to make sure to update the oVirt wiki hooks pages. If users aren't aware of how 
to retrieve
the networking config then we might as well not implement it.

That being said, I'd expose three dictionaries: What's currently configure,
the current request, as well as the proposed end result. It's easy to add
and I see how it would be useful to hook writers. And just to state the obvious,
just like how traditional hooks can change the VM or device XML,
the hook should be able to rewrite the current request contents.
For example, if a user would like to take over host networking configuration,
he could just write a before_setup_networks hook that would configure
networking however he wants, then writes the empty dictionary to the current 
request,
meaning that VDSM wouldn't do anything further with the current setup networks 
request.


Assaf Muller, Cloud Networking Engineer 
Red Hat 

----- Original Message -----
From: "Miguel Angel" <miguelan...@ajo.es>
To: "Adam Litke" <ali...@redhat.com>
Cc: dsull...@redhat.com, a...@ovirt.org, vdsm-de...@fedorahosted.org
Sent: Saturday, January 4, 2014 9:08:17 PM
Subject: Re: [vdsm] Smarter network_setup hooks

Hi Adam 

Thanks for the feedback 

2014/1/3 Adam Litke < ali...@redhat.com > 



On 03/01/14 12:20 +0000, Dan Kenigsberg wrote: 


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. 
[....] 
Seems like a logical thing to do. What specific mechanism do you 
suggest for passing the JSON strings to the hook script? If passed as 
arguments to the hook script we would need to consider shell escaping 
and argv length restrictions. 

As for the libvirt domain xml we pass to other hooks, we write a temporary file 
and we set an environment variable pointing to it before calling the script 


What about writing these out to a special file and adding a new 
getContext() call to the hooking module. A script that is unconcerned 
with the context would not require any changes. But a script that 
wants access would simply do: 

ctx = hooking.getContext() 

and ctx would be the contents of the special file already decoded into 
a native Python object for easy consumption. This could easily be 
extended to any hook which may want to provide some context to 
implementors. 

That would be nice, so scripts written in python wouldn't need to look for, and 
parse 
the file. 

This is an example of a simple hook: 

http://gerrit.ovirt.org/#/c/20330/7/tests/functional/networkTests.py (look 
inside the ValidatesHook decorator) 

It'd be quite simplified. We would also need a "setContext()..." to update 
context with changes. 



One more question comes to mind: Are there any pieces of information 
that we would need to redact from the context (passwords or other 
sensitive information)? 


I think there is no sensitive information as far as I know. 

Greetings, 
Miguel Ángel. 

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to