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 firstname.lastname@example.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel _______________________________________________ vdsm-devel mailing list email@example.com https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel