[vdsm] Smarter network_setup hooks

Mon Jan 6 01:58:07 UTC 2014

----- Original Message -----
> From: "Miguel Angel" <miguelangel at ajo.es>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: dsulliva at redhat.com, vdsm-devel at fedorahosted.org, arch at ovirt.org
> Sent: Sunday, January 5, 2014 11:41:44 PM
> Subject: Re: [vdsm] Smarter network_setup hooks
> 
> 
> 2014/1/5 Livnat Peer < lpeer at redhat.com >
> 
> 
> 
> On 01/05/2014 12:05 PM, Assaf Muller wrote:
> > 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.

My original thought on this was that the hook would be able to mark a device
as configured by it adding a key value like 'hooked': X. This was in order
that if, for example a bond is to be configured by the hook, it would still
stay in the config passed to objectivize but the configurator configure method
for it would be short circuited and X would have the data that is to be put
in the running config by vdsm for that device.

I didn't mature this thought much though... (holidays have kept me a bit busy)

> > 
> 
> 
> I'm not sure if it's easy to get the final state without actually applying
> it, it's easy
> to get an approximate final state (just aggregating dictionaries to networks
> and bondings,
> and erasing the removed ones), but I suppose that'd be good enough :-)
> 
> 
> May be it's good if you can provide a use case for this third "expected"
> final state,
> I can't come up with one. :-)

For this reason I thought of the 'hooked' value, to make the hook writer own
the task of filling in the missing piece of state.

One final consideration that I didn't see arise is the need for having caps
hooks. As soon as we allow setupNetworks hooks it is very necessary that we
enable vdsm caps. One very easy example.

Let us say that I write a hook that makes setupNetworks specified bondings
be configured in the system by libteam/teamd. In order for the changes to
be made visible to the engine we need to fake that team link aggregation
as a bond so that the engine can, in the future, change/delete/use it.
> 
> 
> 
> 
> 
> +1,
> I think the API above would be easy to consume.
> 
> Livnat
> 
> 
> > 
> > Assaf Muller, Cloud Networking Engineer
> > Red Hat
> > 
> > ----- Original Message -----
> > From: "Miguel Angel" < miguelangel at ajo.es >
> > To: "Adam Litke" < alitke at redhat.com >
> > Cc: dsulliva at redhat.com , arch at ovirt.org , vdsm-devel at 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 < alitke at 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 at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 
> 
> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 