9:49 a.m.
------=_Part_29121434_1238593392.1384156173914
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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.
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.
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.
I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for this, however I
also want to discuss the situation:
1. As a user, I can't set custom properties for level < 3.3 which is not good.
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 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.
Regards,
Mike
------=_Part_29121434_1238593392.1384156173914
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"font-family: times new roman, new york,
times, se=
rif; font-size: 12pt; color:
#000000"><div>Hi,<br></div><div><br></div><div=
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.<br></div><div>Fr=
om what I saw the configuration value for custom properties (CustomDevicePr=
operties) is split into 4, one per each version (3.0, 3.1, 3.2, 3.3).<br></=
div><div>Since vNIC profile is located under the DC tree, it takes the DC v=
ersion - 3.2 in this specific
case.<br></div><div><br></div><div>I tried to=
set the config value for 3.2 but got:<br></div><div>$ engine-config -s
Cus=
tomDeviceProperties=3D"{type=3Dinterface;prop=3D{myProp=3D[a-zA-Z0-9-]+}}" =
--cver=3D3.2<br>Cannot set value {type=3Dinterface;prop=3D{myProp=3D[a-zA-Z=
0-9-]+}} to key CustomDeviceProperties. Device custom properties are not su=
pported in version 3.2<br><br></div><div>This is already not very
good, sin=
ce in a 3.2 DC there can be 3.3 clusters with 3.3 hosts that do support cus=
tom device properties.<br></div><div><br></div><div>I
also tried to alter t=
he config value in the DB directly, but the custom properties code ignored =
it since custom properties are not supported in 3.2.<br></div><div>So,
de f=
acto, I have no reasonable way as a user to define custom device properties=
to use for my vNIC profiles in DC <
3.3.<br></div><div><br></div><div>I=
opened the bug <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D10=
28757">https://bugzilla.redhat.com/show_bug.cgi?id=3D1028757</... for this,
=
however I also want to discuss the
situation:</div><div><br></div><div>1. A=
s a user, I can't set custom properties for level < 3.3 which is not goo=
d.<br></div><div> Removing the blocking,
and loading cust=
om properties for all versions would fix the bug and allow using custom dev=
ice properties for older versions, the reasonable place to block this would=
be running a VM (or plugging a
device).<br></div><div> B=
asically this is the lesser
issue..<br></div><div><br></div><div>2. I just =
don't see the added value of splitting the definition of the properties per=
level..<br></div><div> The custom
properties are extensi=
ons 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 ve=
rsion, cluster version?) would make any difference - either the VM can util=
ize the extension given some state of the system, or it can't, but the dete=
rmining factor is not the version but rather the availability of the extens=
ion.<br></div><div> For example, I can
have a hook for vN=
IC altering some property installed on host A and not host B, if the VM run=
s on host A it will get this capability and on host B it won't, regardless =
the DC version the VM is
in.<br></div><div><br></div><div>  =
; This is not to say we shouldn't block custom properties on the engine-VDS=
M API level since it's only available since 3.3, but this is handled by ano=
ther config value (SupportCustomDeviceProperties) which is not alterable by=
the user.<br></div><div> So basically, I
think splitting=
the value per version is over complication and see no added value to the u=
sers, just more maintenance should they choose to use this feature.<br></di=
v><div><br></div><div>Your thoughts
please.<br></div><div><br></div><div><s=
pan name=3D"x"></span>Regards,<br>Mike<span
name=3D"x"></span><br></div><di=
v><br></div></div></body></html>
------=_Part_29121434_1238593392.1384156173914--
4030
days inactive
4030
days old
0 comments
1 participants
participants (1)
-
Mike Kolesnik