[vdsm] Smarter network_setup hooks

[Dan Kenigsberg]

On Sun, Jan 05, 2014 at 08:58:07PM -0500, Antoni Segura Puimedon wrote:
> 
> 
> ----- 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)

Oh, few seconds ago I noted about the idea that hooks scripts would be
able to remove parts of the configuration which they have already
implemented, so that Vdsm proper is left unaware of them.

It's not as flexible as your "hooked=True" suggestion, as it does not
alow to implement only part of a network, but I think that it is
as-powerful and with clearer atomicity.

> 
> > > 
> > 
> > 
> > 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.

Sorry, Toni, I do not understaed how hooked=True is related to the
"expected" dictionary suggested by Assaf.

> 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.

Correct. The same json-based framework devised by Miguel (as well as
Adam's getContext) would come up hand when implementing it.

Dan.