Description of problem: Persist and update engine-config properties such as CustomDeviceProperties and UserDefinedNetworkCustomProperties when upgrading to a major version. Currently we only persist and update engine-config values during minor versions updates, but that is not enough (see BZ 1177803). -When updating to a major version, for example 3.6 > 4.0 or 4.0 > 4.1, the CustomDeviceProperties and UserDefinedNetworkCustomProperties are gone and the default values(security groups) are set. This can cause to some features like 'queues' or 'ethtool_opts' to stop working after upgrade and we have no warning about it. * For example, if we had a 'queues', 'vmfex', 'ifacemacspoof' and 'ovs' key values configured on a 4.0 cluster - CustomDeviceProperties: {type=interface;prop={ovs=.*;ifacemacspoof=^(true|false)$;queues=[1-9][0-9]*;vmfex=^[a-zA-Z0-9_.-]{2,32}$;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}|)$}} version: 4.0 And 'ethtool' configured on the UserDefinedNetworkCustomProperties - UserDefinedNetworkCustomProperties: ethtool_opts=.* version: 4.0 After we will run an upgrade to 4.1 all of this values will be gone. All the above features won't work any more and we will remain only with 'security groups' configured and no warning will appear letting me know that those values keys should be generated again. Version-Release number of selected component (if applicable): rhevm-4.1.0.4-0.1.el7.noarch How reproducible: 100% Steps to Reproduce: 1. Run 4.0 engine and configure some CustomDeviceProperties and UserDefinedNetworkCustomProperties such as: engine-config -s CustomDeviceProperties="{type=interface;prop={ovs=.*;ifacemacspoof=^(true|false)$;queues=[1-9][0-9]*;vmfex=^[a-zA-Z0-9_.-]{2,32}$;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=4.0 engine-config -s 'UserDefinedNetworkCustomProperties=ovs=.*;ovs_aa_sid=.*;ethtool_opts=.*;ipv4_addrs=.*' --cver='4.0' 2. Restart engine service 3. Upgrade to 4.1 version Actual results: All custom properties configurations are gone. We left only with default values. For CustomDeviceProperties with 'security groups' For UserDefinedNetworkCustomProperties with 'bridge_opts' Expected results: 1) Persist and update custom properties during major versions as well 2) At least warn the user/admin that custom properties configurations must be generated again. Additional info: See also https://bugzilla.redhat.com/show_bug.cgi?id=1177803
This bug is not only for "queues"! it's for all properties that are version depended. This bug is not for 'Network' team, but for 'Infra'. - If we not going to set CustomDeviceProperties and UserDefinedNetworkCustomProperties to include default options, then we should: 1) Add question in the 'engine-setup', warning us about and letting us know that the custom properties are about to change and would we like to update them to the new cluster version(who knows when those properties were configured, maybe it was 2 years ago..you can't expect admin remember all the configuration done on the systems during the years, no matter how much smart he is). 2) At least warn the user/admin about that. 3) We all aware of that this has been that way forever, but it doesn't mean that this is the correct or the right behavior.
this could be a (slightly complex) DB upgrade script to populate the value of a newly-available cluster level from the highest pre-existing cluster level.
Dan, quoting you from the thread we had on that " I, too, do not see a very simple and future-proof way to implement this RFEs. If an admin was smart enough to define custom properties, he may be also smart to do it again after a minor version release. We can make "queues" part of the default (for all clusterLevels) to alleviate the specific pain." Adding any logic will only create here confusion and it might also not work in all cases, as you might have different values for different cluster levels. Moving back to network. Talk to me offline if you had other thoughts.
In addition, if you think the entire configuration behavior should be different, please file an RFE on that and we'll triage it when planning upcoming releases, while you handle this issue specifically for 4.1.
Copying "queues" is easy; conditionally copying all values is much harder. Neither is a priority, but only the latter one is what QE want. I have modified the bug title to match what they want, after discussing it with them. Targeting this bug to a specific version (or close it) is completely your prerogative. It may well need to be solved by Integration team.
Reducing severity. This has been that way since forever, and changing that might cause other issues. The owners of keys are the ones that know what the defaults should be, and we shouldn't do it for them. I wanted to close as wontfix, but leaving this open in case we get this prioritized and understand what's the right way to do that.
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly
ok, closing. Please reopen if still relevant/you want to work on it.