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-devel(a)ovirt.org
>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>