Bug 1419329 - [RFE] change the CustomDeviceProperties and UserDefinedNetworkCustomProperties to include default options
Summary: [RFE] change the CustomDeviceProperties and UserDefinedNetworkCustomPropertie...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Infra
Version: 4.1.0.3
Hardware: x86_64
OS: Linux
unspecified
medium vote
Target Milestone: ---
: ---
Assignee: Dan Kenigsberg
QA Contact: Lukas Svaty
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-05 13:26 UTC by Michael Burman
Modified: 2020-04-01 14:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-01 14:47:47 UTC
oVirt Team: Infra
oourfali: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

Description Michael Burman 2017-02-05 13:26:13 UTC
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

Comment 1 Michael Burman 2017-02-08 08:01:06 UTC
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.

Comment 2 Dan Kenigsberg 2017-02-08 09:34:16 UTC
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.

Comment 3 Oved Ourfali 2017-02-13 20:27:48 UTC
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.

Comment 4 Oved Ourfali 2017-02-13 20:41:36 UTC
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.

Comment 5 Dan Kenigsberg 2017-02-14 07:10:07 UTC
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.

Comment 6 Oved Ourfali 2017-02-14 07:14:52 UTC
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.

Comment 7 Michal Skrivanek 2020-03-18 15:46:45 UTC
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

Comment 8 Michal Skrivanek 2020-03-18 15:51:31 UTC
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

Comment 9 Michal Skrivanek 2020-04-01 14:47:47 UTC
ok, closing. Please reopen if still relevant/you want to work on it.

Comment 10 Michal Skrivanek 2020-04-01 14:51:11 UTC
ok, closing. Please reopen if still relevant/you want to work on it.


Note You need to log in before you can comment on or make changes to this bug.