Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)
- Original Message -
> Hi Mike,
>
> - Original Message -
> > From: "Mike Kolesnik"
> > To: "engine-devel"
> > Cc: "Barak Azulay" , "Martin Perina"
> > , "Livnat Peer" ,
> > "Itamar Heim"
> > 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 ...
>
But the effective version is the DC version as I explained.
In a DC 3.0-3.3 I can have clusters which the minimal version is the DC
version, and the maximal version is 3.3.
For example I can have the following:
DC - version 3.0
+ Cluster 1 - version 3.0
+ Cluster 2 - version 3.1
+ Cluster 3 - version 3.2
+ Cluster 4 - version 3.3
In this constellation, I could use custom device properties only on Cluster 4,
but it's not possible to define them since the vNIC profile is using the DC
version 3.0.
So effectively this feature is not usable to me unless I use a 3.3 DC.
> >
> > 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
Custom properties is not for specifying which features are enabled, there is a
whole other mechanism for that..
Custom properties is for hooks (and other possible extensions), which by
definition are not something that is guaranteed to exist so I see no point to
force the user to update multiple configurations and cause confusion for him..
>
> > 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
Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)
- Original Message -
> From: "Mike Kolesnik"
> To: "Martin Perina"
> Cc: engine-devel@ovirt.org
> Sent: Monday, November 11, 2013 10:48:40 AM
> Subject: Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile
> = not working (< 3.3)
>
>
> - Original Message -
> > Hi Mike,
> >
> > - Original Message -
> > > From: "Mike Kolesnik"
> > > To: "engine-devel"
> > > Cc: "Barak Azulay" , "Martin Perina"
> > > , "Livnat Peer" ,
> > > "Itamar Heim"
> > > 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 ...
> >
>
> But the effective version is the DC version as I explained.
>
> In a DC 3.0-3.3 I can have clusters which the minimal version is the DC
> version, and the maximal version is 3.3.
> For example I can have the following:
> DC - version 3.0
> + Cluster 1 - version 3.0
> + Cluster 2 - version 3.1
> + Cluster 3 - version 3.2
> + Cluster 4 - version 3.3
>
> In this constellation, I could use custom device properties only on Cluster
> 4, but it's not possible to define them since the vNIC profile is using the
> DC version 3.0.
> So effectively this feature is not usable to me unless I use a 3.3 DC.
No, it's not usable for you, because you are not using device custom properties
in a way that they were designed. You want to specify custom device
properties per DC version (or general version), but they were designed
to be specified per cluster level. Because currently currently if you
specify properties for cluster version 3.3, they can be used for all
clusters with version 3.3 regardless of DC version they are members of ...
>
> > >
> > > 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 fo
Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)
On 11/11/2013 11:48 AM, Mike Kolesnik wrote:
- Original Message -
Hi Mike,
- Original Message -
From: "Mike Kolesnik"
To: "engine-devel"
Cc: "Barak Azulay" , "Martin Perina"
, "Livnat Peer" ,
"Itamar Heim"
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 ...
But the effective version is the DC version as I explained.
In a DC 3.0-3.3 I can have clusters which the minimal version is the DC
version, and the maximal version is 3.3.
For example I can have the following:
DC - version 3.0
+ Cluster 1 - version 3.0
+ Cluster 2 - version 3.1
+ Cluster 3 - version 3.2
+ Cluster 4 - version 3.3
In this constellation, I could use custom device properties only on Cluster 4,
but it's not possible to define them since the vNIC profile is using the DC
version 3.0.
So effectively this feature is not usable to me unless I use a 3.3 DC.
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
Custom properties is not for specifying which features are enabled, there is a
whole other mechanism for that..
Custom properties is for hooks (and other possible extensions), which by
definition are not something that is guaranteed to exist so I see no point to
force the user to update multiple configurations and cause confusion for him..
as martin explained, we have predefined custom properties, which are
based on the vdsm version, and hence are actually features we know to
expose or not to expose.
user-defined custom properties - are up to the admin, but we let these
be at cluster level as well to allow more granularity.
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'
Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)
- Original Message -
> On 11/11/2013 11:48 AM, Mike Kolesnik wrote:
> >
> > - Original Message -
> >> Hi Mike,
> >>
> >> - Original Message -
> >>> From: "Mike Kolesnik"
> >>> To: "engine-devel"
> >>> Cc: "Barak Azulay" , "Martin Perina"
> >>> , "Livnat Peer" ,
> >>> "Itamar Heim"
> >>> 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 ...
> >>
> >
> > But the effective version is the DC version as I explained.
> >
> > In a DC 3.0-3.3 I can have clusters which the minimal version is the DC
> > version, and the maximal version is 3.3.
> > For example I can have the following:
> > DC - version 3.0
> > + Cluster 1 - version 3.0
> > + Cluster 2 - version 3.1
> > + Cluster 3 - version 3.2
> > + Cluster 4 - version 3.3
> >
> > In this constellation, I could use custom device properties only on Cluster
> > 4, but it's not possible to define them since the vNIC profile is using
> > the DC version 3.0.
> > So effectively this feature is not usable to me unless I use a 3.3 DC.
> >
> >>>
> >>> 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
> >
> > Custom properties is not for specifying which features are enabled, there
> > is a whole other mechanism for that..
> >
> > Custom properties is for hooks (and other possible extensions), which by
> > definition are not something that is guaranteed to exist so I see no point
> > to force the user to update multiple configurations and cause confusion
> > for him..
>
> as martin explained, we have predefined custom properties, which are
> based on the vdsm version, and hence are actually features we know to
> expose or not to expose.
> user-defined custom properties - are up to the admin, but we let these
> be at cluster level as well to allow more granularity.
There are no predefined prope
Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)
On 11/20/2013 09:07 AM, Mike Kolesnik wrote:
- Original Message -
On 11/11/2013 11:48 AM, Mike Kolesnik wrote:
- Original Message -
Hi Mike,
- Original Message -
From: "Mike Kolesnik"
To: "engine-devel"
Cc: "Barak Azulay" , "Martin Perina"
, "Livnat Peer" ,
"Itamar Heim"
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 ...
But the effective version is the DC version as I explained.
In a DC 3.0-3.3 I can have clusters which the minimal version is the DC
version, and the maximal version is 3.3.
For example I can have the following:
DC - version 3.0
+ Cluster 1 - version 3.0
+ Cluster 2 - version 3.1
+ Cluster 3 - version 3.2
+ Cluster 4 - version 3.3
In this constellation, I could use custom device properties only on Cluster
4, but it's not possible to define them since the vNIC profile is using
the DC version 3.0.
So effectively this feature is not usable to me unless I use a 3.3 DC.
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
Custom properties is not for specifying which features are enabled, there
is a whole other mechanism for that..
Custom properties is for hooks (and other possible extensions), which by
definition are not something that is guaranteed to exist so I see no point
to force the user to update multiple configurations and cause confusion
for him..
as martin explained, we have predefined custom properties, which are
based on the vdsm version, and hence are actually features we know to
expose or not to expose.
user-defined custom properties - are up to the admin, but we let these
be at cluster level as well to allow more granularity.
There are no predefined properties here, only user defined properties.
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
Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)
- Original Message -
> On 11/20/2013 09:07 AM, Mike Kolesnik wrote:
> > - Original Message -
> >> On 11/11/2013 11:48 AM, Mike Kolesnik wrote:
> >>>
> >>> - Original Message -
> Hi Mike,
>
> - Original Message -
> > From: "Mike Kolesnik"
> > To: "engine-devel"
> > Cc: "Barak Azulay" , "Martin Perina"
> > , "Livnat Peer" ,
> > "Itamar Heim"
> > 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 ...
>
> >>>
> >>> But the effective version is the DC version as I explained.
> >>>
> >>> In a DC 3.0-3.3 I can have clusters which the minimal version is the DC
> >>> version, and the maximal version is 3.3.
> >>> For example I can have the following:
> >>> DC - version 3.0
> >>>+ Cluster 1 - version 3.0
> >>>+ Cluster 2 - version 3.1
> >>>+ Cluster 3 - version 3.2
> >>>+ Cluster 4 - version 3.3
> >>>
> >>> In this constellation, I could use custom device properties only on
> >>> Cluster
> >>> 4, but it's not possible to define them since the vNIC profile is using
> >>> the DC version 3.0.
> >>> So effectively this feature is not usable to me unless I use a 3.3 DC.
> >>>
> >
> > 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
> >>>
> >>> Custom properties is not for specifying which features are enabled, there
> >>> is a whole other mechanism for that..
> >>>
> >>> Custom properties is for hooks (and other possible extensions), which by
> >>> definition are not something that is guaranteed to exist so I see no
> >>
Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)
On 11/20/2013 09:31 AM, Mike Kolesnik wrote:
- Original Message -
On 11/20/2013 09:07 AM, Mike Kolesnik wrote:
- Original Message -
On 11/11/2013 11:48 AM, Mike Kolesnik wrote:
- Original Message -
Hi Mike,
- Original Message -
From: "Mike Kolesnik"
To: "engine-devel"
Cc: "Barak Azulay" , "Martin Perina"
, "Livnat Peer" ,
"Itamar Heim"
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 ...
But the effective version is the DC version as I explained.
In a DC 3.0-3.3 I can have clusters which the minimal version is the DC
version, and the maximal version is 3.3.
For example I can have the following:
DC - version 3.0
+ Cluster 1 - version 3.0
+ Cluster 2 - version 3.1
+ Cluster 3 - version 3.2
+ Cluster 4 - version 3.3
In this constellation, I could use custom device properties only on
Cluster
4, but it's not possible to define them since the vNIC profile is using
the DC version 3.0.
So effectively this feature is not usable to me unless I use a 3.3 DC.
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
Custom properties is not for specifying which features are enabled, there
is a whole other mechanism for that..
Custom properties is for hooks (and other possible extensions), which by
definition are not something that is guaranteed to exist so I see no
point
to force the user to update multiple configurations and cause confusion
for him..
as martin explained, we have predefined custom properties, which are
based on the vdsm version, and hence are actually features we know to
expose or not to expose.
user-defined custom properties - are up to the admin, but we let these
be at cluster level as well to allow more granularity.
There are no predefined properties here, only user defined properties.
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 exa
Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)
- Original Message -
> On 11/20/2013 09:31 AM, Mike Kolesnik wrote:
> >
> > - Original Message -
> >> On 11/20/2013 09:07 AM, Mike Kolesnik wrote:
> >>> - Original Message -
> On 11/11/2013 11:48 AM, Mike Kolesnik wrote:
> >
> > - Original Message -
> >> Hi Mike,
> >>
> >> - Original Message -
> >>> From: "Mike Kolesnik"
> >>> To: "engine-devel"
> >>> Cc: "Barak Azulay" , "Martin Perina"
> >>> , "Livnat Peer" ,
> >>> "Itamar Heim"
> >>> 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 ...
> >>
> >
> > But the effective version is the DC version as I explained.
> >
> > In a DC 3.0-3.3 I can have clusters which the minimal version is the DC
> > version, and the maximal version is 3.3.
> > For example I can have the following:
> > DC - version 3.0
> > + Cluster 1 - version 3.0
> > + Cluster 2 - version 3.1
> > + Cluster 3 - version 3.2
> > + Cluster 4 - version 3.3
> >
> > In this constellation, I could use custom device properties only on
> > Cluster
> > 4, but it's not possible to define them since the vNIC profile is using
> > the DC version 3.0.
> > So effectively this feature is not usable to me unless I use a 3.3 DC.
> >
> >>>
> >>> 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
Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)
- Original Message -
> From: "Mike Kolesnik"
> To: "Itamar Heim"
> Cc: engine-devel@ovirt.org
> Sent: Wednesday, November 20, 2013 9:41:45 AM
> Subject: Re: [Engine-devel] Fwd: Custom properties per device + vNIC profile
> = not working (< 3.3)
>
> - Original Message -
> > On 11/20/2013 09:31 AM, Mike Kolesnik wrote:
> > >
> > > - Original Message -
> > >> On 11/20/2013 09:07 AM, Mike Kolesnik wrote:
> > >>> - Original Message -
> > >>>> On 11/11/2013 11:48 AM, Mike Kolesnik wrote:
> > >>>>>
> > >>>>> - Original Message -
> > >>>>>> Hi Mike,
> > >>>>>>
> > >>>>>> - Original Message -
> > >>>>>>> From: "Mike Kolesnik"
> > >>>>>>> To: "engine-devel"
> > >>>>>>> Cc: "Barak Azulay" , "Martin Perina"
> > >>>>>>> , "Livnat Peer" ,
> > >>>>>>> "Itamar Heim"
> > >>>>>>> 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 ...
> > >>>>>>
> > >>>>>
> > >>>>> But the effective version is the DC version as I explained.
> > >>>>>
> > >>>>> In a DC 3.0-3.3 I can have clusters which the minimal version is the
> > >>>>> DC
> > >>>>> version, and the maximal version is 3.3.
> > >>>>> For example I can have the following:
> > >>>>> DC - version 3.0
> > >>>>> + Cluster 1 - version 3.0
> > >>>>> + Cluster 2 - version 3.1
> > >>>>> + Cluster 3 - version
