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" <mkolesni(a)redhat.com&gt; >>>>>>> To: "engine-devel" <engine-devel(a)ovirt.org&gt; >>>>>>> Cc: "Barak Azulay" <bazulay(a)redhat.com&gt;, "Martin Perina" >>>>>>> <mperina(a)redhat.com&gt;, "Livnat Peer" <lpeer(a)redhat.com&gt;, >>>>>>> "Itamar Heim" <iheim(a)redhat.com&gt; >>>>>>> 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 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 ... >>>>> >>>>> Since I can have cluster 3.3 in a DC < 3.3, and this is the upgrade >>>>> path >>>>> for existing users, >>>>> I'd argue that the bug is severe enough and should be fixed asap even >>>>> for >>>>> 3.3 versions. >>>> >>>> please note that if you expose this at cluster level and not DC level, >>>> you need to make sure to verify it when moving a VM between clusters in >>>> same DC. >>>> also, if this is somehow related to logical networks, not vnic specific, >>>> than logical networks are DC level entities. >>>> >>>> >>> >>> OK but my point was that a custom properties is not meant to be split by >>> versions since >>> by definition of it, a hook might or might not exist on a given host >>> (regardless of the host version). >>> It only imposes more strain on the user to define possible custom >>> properties by version.. >>> >>> I see no value to users in this approach, only more work and >>> unclearness.. >>> >>> Mind you, hook is not a "feature" that is explicitly supported on a given >>> version, but an extension >>> mechanism which can have 3rd party extensions that might or might not >>> exist >>> on a given host, but this >>> won't stop an action from occurring (i.e. VM would still start if a hook >>> is >>> missing but some custom >>> property was sent). >>> >>> Also the original bug still exists because even though the vNIC is >>> sitting >>> at VM which is in cluster >>> (thus in effect having access to the cluster version), the profile sits >>> under network (which, as you >>> mention, is DC level entity). >>> So for the user using a DC < 3.3 there is no option to use this feature >>> even though he can have 3.3 >>> clusters in his DC. >>> >> >> except some hooks are shipped as required, and some custom properties >> are supported by vdsm even without hooks. >> so allowing to specify they are 'there' for a specific vdsm version is >> useful. >> > > Seems to me you're referring to things that should be in a predefined > properties > list, which as I mentioned doesn't exist for this feature. > 1. maybe it should. 2. still, i think the granularity isn't hurting in this case - more likely a hook will be needed, or not needed, in specific compat versions as features are added/removed from the product, even for custom hooks.