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

[Moti Asayag]

On 01/20/2013 11:18 AM, Dan Kenigsberg wrote:
> 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.
> 

I think that having a dedicated properties map for custom properties
will ease its usage, therefore I support your proposal of adding a
specific custom properties map.

I think that we should move the discussion from @users to @arch.