Description of problem: engine-config -s CustomDeviceProperties Deleted/removed after rhevm-setup update. Every time when updating the engine to a new build, it removes the CustomDeviceProperties from the engine config and this properties needed to be configured again in the engine-config. For example: engine-config -s CustomDeviceProperties="{type=interface;prop={ifacemacspoof=^(true|false)$;queues=[1-9][0-9]*;SecurityGroups=^(?:(?:[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}, *)*[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}|)$}}" --cver=3.5 after upgrading the engine, queues and ifacemacspoof properties will be deleted. security group will stay(cause it's a default property). - This is happens only with CustomDeviceProperties from what i have noticed. - 'UserDefinedNetworkCustomProperties=ethtool_opts=.*' --cver='3.5' for example will stay with no change after engine upgrade. So maybe it's because in the CustomDeviceProperties there is no separation between the pre-defind and the user-defind. How reproducible: 100% Steps to Reproduce: 1. Run: engine-config -s CustomDeviceProperties="{type=interface;prop={ifacemacspoof=^(true|false)$;queues=[1-9][0-9]*;SecurityGroups=^(?:(?:[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}, *)*[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}|)$}}" --cver=3.5 2. Restart engine and check if properties has been configured as expected. 3. Upgrade/update engine. 'yum update rhevm-setup' and then 'rhevm-setup' it can be from any build, vt 13.4,13.1,12 and lower, this is reproducible on any engine version. 4. Check if CustomDeviceProperties stayed with no change in engine-config after engine upgrade. Actual results: CustomDeviceProperties has been deleted/removed Expected results: CustomDeviceProperties should stay with no change after engine upgrade
Note that the fix This will take affect only when upgrading to other minor version e.g. from 3.5.0 to 3.5.1. For a major version, a new key is generated with the default value.
Hi Eli, Yaniv How should i test and verify this bug? i'm not sure this is possible... - The fix is done for 3.6 version and only supported for upgrade from minor to other minor version. I actually waited for the second official 3.6 release in order to verify this bug(wanted to be sure that keys for CustomDeviceProperties are not removed after upgrade) , but upgrade from 3.6.0-1 >> 3.6.0-2 is actually not supported and my upgrade process failed. I couldn't run upgrade from 3.6.0-1 to 3.6.0-2 and it means i couldn't test the fix for this bug. So, if upgrade from minor versions like 3.6.0-1 to 3.6.0-2 is not supported and major version will delete and generate keys with default values, it means i can't test or verify this bug. Am i right?
(In reply to Michael Burman from comment #2) > Hi Eli, Yaniv > > Am i right? Seems so, I will wait for Yaniv's reply on that
(In reply to Eli Mesika from comment #3) > (In reply to Michael Burman from comment #2) > > Hi Eli, Yaniv > > > > Am i right? > > Seems so, I will wait for Yaniv's reply on that You can do a upgrade between betas in most cases, please test it using those builds. Once released.
OK, i will do that, thank you Yaniv.
And again can't verify this bug because upgrade/update from 3.6.0-0.0.master.20150519172219.git9a2e2b3.el6.noarch(3.6.0-2.1) >> 3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch(3.6.0-3) Has been failed.
After running the workaround for upgrade from 3.6.0-2.1 >> 3.6.0-3 i finely managed to verify this bug. Verified on - 3.6.0-0.0.master.20150627185750.git6f063c1.el6 after running upgrade from 3.6.0-0.0.master.20150519172219.git9a2e2b3.el6.noarch(3.6.0-2.1) --> 3.6.0-0.0.master.20150627185750.git6f063c1.el6.noarch(3.6.0-3) All the keys in CustomDeviceProperties been persist after upgrade.