On 10/16/2012 09:31 AM, Livnat Peer wrote:
On 16/10/12 08:52, Mike Kolesnik wrote:
----- Original Message -----
On 10/10/12 16:47, Igor Lvovsky wrote:
As you know vdsm has hooks mechanism and we already support dozen
of hooks for different needs.
Now it's a network's time.
We would like to get your comments regarding our proposition for
network related hooks.
In general we are planning to prepare framework for future support
of bunch network related hooks.
Some of them already proposed by Itzik Brown  and Dan Yasny .
Below you can find the additional hooks list that we propose:
Many of the API calls bellow are deprecated. Why do we want to add
before/after to deprecated APIs?
They are actually still very much in use with the REST API.
Deprecate does not mean "not in use" but "not using it going forward".
Today if a user is using 3.1 cluster/DC in the UI or the setupNetwork
API (which is the recommended way to configure your network in 3.1 and
in future versions) the hooks for add/edit-Network won't get activated
and that is confusing to the users (and the developers).
Perhaps we should address just the logical entry points instead of specific
A command such as setup networks can trigger multiple logical events in which
hooks can be planted (same goes for edit network in a smaller scale).
What you are suggesting above is to deviate from the current hook
mechanism we have in VDSM and add some logic to where/when we activate
That's an interesting suggestion, I suggest to write a wiki page and
start thinking of the implementation implications of it.
Since I like the idea I'll work with you on the wiki and we'll see if we
can get something more useful to the users and send a formal proposal.
question is there is any high demand/priority for network hooks other
than hotplug nic, and do we have a clear vision of a stable api for them.
one thing to consider is allowing to define custom properties at logical
network and virtual nic level though.
vdsm-devel mailing list