[vdsm] Per device custom properties

[Dan Kenigsberg]

adding arch at ovirt, as this feature is cross sub-project

On Sun, Mar 17, 2013 at 09:50:20AM -0400, Assaf Muller wrote:
> Hi all,
> 
> Right now we have the ability to define VM-wide properties that may be
> used by hooks.
> It is time we have the same functionality on a device basis:
> http://www.ovirt.org/Features/Device_Custom_Properties

This feature page needs some love and attention.

* I received a private communication about the suggested GUI: there
  should not be an independent vNIC action called "custom Properties" -
  the dialog for editing per-vNIC custom properties should be part of
  defining a new vNIC or editting an existing one. I believe Eldan (our
  GUI designer) concurs.

* http://www.ovirt.org/Features/Device_Custom_Properties#Engine is
  rather lacking concrete details. Yair, could you improve it, as well
  as the completely empty REST section?

>
> For example: If the VM has 2 disks called disk1 and disk2, and two
> NICs called nic1 and nic2, and the admin (From the engine) added a
> custom property qos: 0.5 for nic1 and a custom property defrag: None
> for disk2. When the VM is started we'll run a hook for nic1 with its
> XML and qos: 0.5 added as an environment variable, and a hook for
> disk2 with its XML and defrag: None.
> 
> When a device is hot plugged and it has custom properties we'll run
> that hook as well.
> 
> Implementation-wise, hot plug/unplug for disks and NICs is dead simple
> - vmCreate is more problematic:
> If the user set a custom property called 'qos: 0.8' for nic3, I'd want
> it exposed as an environment variable called 'qos' for hot plug nic
> hooks, but for vmCreate I'd like to prefix the nic's alias.  However,
> when vmCreate is called we don't have the aliases for NICs and disks. 
> 
> The proposed solution is to create a new hook point called something
> like: 'before_device_creation' that will be called before vmCreate.
> We'll then call that hook specifically for devices that contains
> custom properties, as described in the second paragraph of this mail. 
> 
> 
> I would love to hear smarter ideas before I move forward. Thanks!

I find it quite intuitive, but I'd rather hear if it feats Izik's use
case.

Dan.