On Sun, Jan 05, 2014 at 05:05:59AM -0500, 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.

I do not see why "current" is a good idea to pass from Vdsm to the hook
- if the hook needs it, it could compute the current state on its own.

What do you mean by the "proposed end result"? setupNetwork API works in
allows "diffs" relative to the current state. The end result, however,
may even be unexpressable within the scope of our API (that's exactly
what hooks are for!). And again, if Vdsm is able to calculate the end
result based on the current state + diff, so can the hook itself.

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

This would be a very good additions. Cascaded scripts would then be able
to drop parts of the command, which they have implemented themselves.

vdsm-devel mailing list

Reply via email to