[Users] vnic : add a custom properties and use it in vdsm_hook

[Dan Kenigsberg]

On Tue, Jan 15, 2013 at 08:26:11AM -0500, Moti Asayag wrote:
> On 12/14/2012 02:32 PM, Dan Kenigsberg wrote:
> > On Thu, Dec 06, 2012 at 09:32:03AM +0100, Benoit ML wrote:
> >> Hello,
> >>
> >> Thanks for your answer. Well i've the same feeling : it would be great
> >> but need some works to have a per device custom properties : database
> >> schema upgrade, code interfaces modifications, ... and I'm not a java
> >> dev.
> > 
> > Neither do I... But if we get an agreement about the api we can start
> > working, at least in the vdsm side.
> > 
> > While we deliberate, please note that we now have a new veb that is
> > capable of changing VM connectivity (updateDevice) which does not have
> > any hookpoint at all. I think that hook users would be interested to be
> > notified when a nic is connected/disconnected to a new network, so I
> > really hope that someone finds the time to implement it.
> > 
> >>
> >>
> >> Regards,
> >>
> >> 2012/12/2 Dan Kenigsberg <danken at redhat.com>:
> >>> On Fri, Nov 30, 2012 at 02:15:31PM +0100, Benoit ML wrote:
> >>>> Hello Evrybody,
> >>>>
> >>>> Is there a way to add custom properties for a nic ? and use it in vdsm_hooks ?
> >>>>
> >>>> The objectife is to redefine some network parameters of a vnic at the
> >>>> vm boot ... (such per vnic bandwitchs, per vnic vlan, and so on) and
> >>>> maybe use openvswitch ...
> >>>
> >>> I would very much like to see something like that, but at the moment,
> >>> custom properties exist only in the VM level.
> >>>
> >>> You could hack around it by defining nicproperties that accepts a
> >>> nested dictionary of {nicID: {property: value}, }
> >>> But it would be a cruel and unusual punishment to edit it.
> >>>
> >>> Not long ago, Itzik and Mark discussed the need of per-nic custom
> >>> properties on Gerrit. At least on the Vdsm side, it would rather easy to
> >>> define: I suggest that each "device" definition would have a "custom"
> >>> attribute, similar to the per-vm one. This should be a dictionary
> >>> holding unicode key/value pairs, that would be passed as
> >>> <devalias>_<customname> environment variables to the hook script.
> >>>
> >>> I know Engine much less, but I do not suppose it would be hard to model
> >>> something like this there.
> >>>
> >>> Dan.
> 
> There is already a field on VM device level named specParams that can serve this
> purpose. VmDevice.specParams is defined as a map.
> It is used in few scenarios such as VM payload (on vm level).
> 
> The specParams is persisted to vm devices table and passes to any VDSM command
> start of 3.1 for the device, therefore minor changes are required to DB layer
> and to vdsbroker module to complete this functionality.
> 
> Most of the work is on exposing the map to the clients: Since the specParams
> degined to be specificed per VM device, it makes sense to configure them on
> a specific entity action: Add/Update vNic.
> 
> The specParams could be exposed as another parameter of the actions (Add/Update vNic) 
> and modelled as an attribute of the NIC property - probably should be further discussed 
> on arch/engine-devel.

My only problem with this approach is that specParams is used
extensively as an Enging/Vdsm communication channel, regardless of
hooks. For example, it controls how much vram is allocated per spice
video card. It means that unlike in per-Vm properties, the user does not
have the prerogative to choose whatever keynames that he likes. Future
additions to that communication channel may break users' hooks.

On top of that, several of the values in specParams are dictionaries
themselves, not plain unicode strings.

We could filter plain strings from specParams into the environment of
hook scripts, and warn that Engine may choose to directly use your
custom keys. It smells like an over-complicated thing to write in the
documentation of the hook interface.