[Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)

[Martin Perina]

Hi Mike,

----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "Barak Azulay" <bazulay at redhat.com>, "Martin Perina" <mperina at redhat.com>, "Livnat Peer" <lpeer at redhat.com>,
> "Itamar Heim" <iheim at redhat.com>
> Sent: Monday, November 11, 2013 8:49:33 AM
> Subject: Custom properties per device + vNIC profile = not working (< 3.3)
> 
> Hi,
> 
> I came across a situation where I wanted to define custom properties on a
> vNIC profile sitting under a network in a 3.2 data center.
> From what I saw the configuration value for custom properties
> (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1,
> 3.2, 3.3).
> Since vNIC profile is located under the DC tree, it takes the DC version -
> 3.2 in this specific case.

Custom Device Properties were designed to be specified for each cluster version
independently, it doesn't care about DC version. AFAIK cluster version defines
what features are available ...

> 
> I tried to set the config value for 3.2 but got:
> $ engine-config -s
> CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}"
> --cver=3.2
> Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key
> CustomDeviceProperties. Device custom properties are not supported in
> version 3.2
> 
> This is already not very good, since in a 3.2 DC there can be 3.3 clusters
> with 3.3 hosts that do support custom device properties.

Specify your properties for 3.3 version, since they will be used in 3.3 clusters ...

> 
> I also tried to alter the config value in the DB directly, but the custom
> properties code ignored it since custom properties are not supported in 3.2.
> So, de facto, I have no reasonable way as a user to define custom device
> properties to use for my vNIC profiles in DC < 3.3.

There are two configuration properties  for Custom Device Properties:

1) SupportCustomDeviceProperties
     - defines in what version properties are supported
     - cannot be altered by users of course

2) CustomDeviceProperties
     - holds properties specification for each version
     - can be defined using engine-config

> 
> I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for
> this, however I also want to discuss the situation:

I looked at the bug and the problem is, that management network profile
is bound to DC and not the Cluster. And that's something we never thought of ...

> 
> 1. As a user, I can't set custom properties for level < 3.3 which is not
> good.

Well, it's 3.3 feature, so it looks OK for me 

> Removing the blocking, and loading custom properties for all versions would
> fix the bug and allow using custom device properties for older versions, the
> reasonable place to block this would be running a VM (or plugging a device).
> Basically this is the lesser issue..
> 
> 2. I just don't see the added value of splitting the definition of the
> properties per level..

The idea behind the version splitting was:

1) We have a device with a feature that doesn't work correctly with version 3.3,
   but it's fixed in 3.4
2) By specifying custom property per version we cane disable this feature for 3.3
   and enable for 3.4
   
> The custom properties are extensions which might or might not be available to
> a certain VM, I don't see how having different sets of custom properties per
> version (what version, DC version, cluster version?) would make any
> difference - either the VM can utilize the extension given some state of the
> system, or it can't, but the determining factor is not the version but
> rather the availability of the extension.
> For example, I can have a hook for vNIC altering some property installed on
> host A and not host B, if the VM runs on host A it will get this capability
> and on host B it won't, regardless the DC version the VM is in.
> 
> This is not to say we shouldn't block custom properties on the engine-VDSM
> API level since it's only available since 3.3, but this is handled by
> another config value (SupportCustomDeviceProperties) which is not alterable
> by the user.
> So basically, I think splitting the value per version is over complication
> and see no added value to the users, just more maintenance should they
> choose to use this feature.
> 
> Your thoughts please.

AFAIK only network and storage team wanted to use device custom properties
in 3.3 version, but I'm not sure what's current usage status.

But IMHO it's too late for 3.3 to change specification ...

Martin