Mid-thread summary: First some terminology so we're all on the same page: 'request' - The setupNetworks that just arrived 'running config' - If unified persistence is being used - All networking on the host as VDSM sees it 'expected' - If unified persistence is being used - The running config after the effects of the request, but before the hook is ran
I think we all agree that we have to expose the 'request' to the hook. However, there's two different approaches: 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 then delete that network from the request, so VDSM will only continue to configure the 2nd network). 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 could configure only the NICs (For example) and VDSM would configure the rest, whereas the first idea means that the hook would have to configure the entire network (Bridge, VLANs, bonds, and all 3 NICs) and then remove that network from the request. The disadvantage of this method is that it would be harder to implement, and have references to the hooks flag throughout all of VDSM. Then there's the matter of IF to expose the 'running config' and 'expected'. 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?), 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 over hook writers. Either way, let's get some votes in a timely manner so we could manage to implement this for 3.4. Assaf Muller, Cloud Networking Engineer Red Hat ----- Original Message ----- From: "Adam Litke" <ali...@redhat.com> To: "Miguel Angel" <miguelan...@ajo.es> Cc: dsull...@redhat.com, a...@ovirt.org, vdsm-de...@fedorahosted.org Sent: Monday, January 6, 2014 3:32:07 PM Subject: Re: [vdsm] Smarter network_setup hooks On 04/01/14 20:08 +0100, Miguel Angel wrote: >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. Yeah seems reasonable. Then hook scripts can become much simpler and easier to read and write: ctx = hooking.getContext() ctx['foo'] = 'bar' hooking.setContext(ctx) > > >> >> 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
