Bug 1419329
Summary: | [RFE] change the CustomDeviceProperties and UserDefinedNetworkCustomProperties to include default options | ||
---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Michael Burman <mburman> |
Component: | BLL.Infra | Assignee: | Dan Kenigsberg <danken> |
Status: | CLOSED DEFERRED | QA Contact: | Lukas Svaty <lsvaty> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.1.0.3 | CC: | bugs, mperina, myakove |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | Flags: | oourfali:
ovirt-future?
rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack? |
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-04-01 14:47:47 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Michael Burman
2017-02-05 13:26:13 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. 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 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. ok, closing. Please reopen if still relevant/you want to work on it. |