[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vdsm-devel
Subject:    [vdsm] [Engine-devel] Network related hooks in vdsm
From:       iheim () redhat ! com (Itamar Heim)
Date:       2012-10-18 0:18:54
Message-ID: 507F4AEE.9060506 () redhat ! com
[Download RAW message or body]

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.


[prev in list] [next in list] [prev in thread] [next in thread]