Re: [Users] vnic : add a custom properties and use it in vdsm_hook
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(a)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.