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.

Livnat

>>
>>> Note: In the first stage we can implement these hooks without any
>>> parameters, just to provide an entry point
>>>  for simple hooks.
>>>
>>> Networks manipulation:
>>> - before_add_network(conf={}, customProperty={})
>>> - after_add_network(conf={}, customProperty={})
>>> - before_del_network(conf={}, customProperty={})
>>> - after_del_network(conf={}, customProperty={})
>>> - before_edit_network(conf={}, customProperty={})
>>> - after_edit_network(conf={}, customProperty={})
>>> - TBD
>>>
>>> Bondings manipulations:
>>> - before_add_bond(conf={}, customProperty={})
>>> - after_add_bond(conf={}, customProperty={})
>>> - before_del_bond(conf={}, customProperty={})
>>> - after_del_bond(conf={}, customProperty={})
>>> - before_edit_bond(conf={}, customProperty={})
>>> - after_edit_bond(conf={}, customProperty={})
>>> - TBD
>>>
>>> General purpose:
>>> - before_persist_network
>>> - after_persist_network
>>>
>>>
>>> Now we just need to figure out the use cases.
>>>
>>> Your input more than welcome...
>>>
>>> [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for
>>> NIC hotplug
>>> [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX
>>> support
>>>
>>>
>>> Regards,
>>>     Igor Lvovsky
>>> _______________________________________________
>>> Engine-devel mailing list
>>> engine-de...@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> engine-de...@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to