[Engine-devel] [vdsm] Network related hooks in vdsm

[Itamar Heim]

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.