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:
Hi everyone, 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 [1] and Dan Yasny [2].
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 hooks 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 commands. 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 hooks.
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.