Bug 1089093
| Summary: | [RFE] Rework engine configuration | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Alon Bar-Lev <alonbl> | ||||
| Component: | RFEs | Assignee: | Martin Perina <mperina> | ||||
| Status: | CLOSED DEFERRED | QA Contact: | Pavel Stehlik <pstehlik> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | --- | CC: | bazulay, bugs, mgoldboi, mperina, oourfali, rbalakri, rgolan, s.kieske, srevivo | ||||
| Target Milestone: | --- | Keywords: | CodeChange, FutureFeature, Improvement, Reopened | ||||
| Target Release: | --- | Flags: | oourfali:
ovirt-future?
ylavi: planning_ack? ylavi: devel_ack? ylavi: testing_ack? |
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Enhancement | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-06-08 05:26:54 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: | |||||||
| Attachments: |
|
||||||
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug. Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release. Martin - moved to you. We'll consider that (or other configuration changes) for 4.0. (In reply to Oved Ourfali from comment #4) > Martin - moved to you. > We'll consider that (or other configuration changes) for 4.0. Time to decide. I'm for moving it from 4.0 (and in fact, closing with WONTFIX). I'll push that to ovirt-future, as we should consider changing the configuration in future versions. Roy, please add your idea to this and let's decide if we wish to pursue this or close-defer. (In reply to Yaniv Kaul from comment #7) > Roy, please add your idea to this and let's decide if we wish to pursue this > or close-defer. We aren't going to re-open the configuration at this point. We can consider improving/changing/re-implementing it in KubeVirt. |
Created attachment 887348 [details] convert.py CURRENT IMPLEMENTATION ConfigValues.java 1. single enumeration of all configuration values. 2. hardcoded defaults (if missing from vdc_options table). 3. java magic for indirect reference of configuration values (aka "behavior"). ConfigurationValues.java 1. UI exposed config values. 2. Rule management. vdc_options table 1. columns: option_name, option_value, version 2. 'general' a special version for all versions, but if not provided explicit value per version is required. engine-config.properties 1. holds configuration for the engine-config utilities. 2. contains description for config values, type. 3. contains input validation hint. PROBLEMS IN CURRENT IMPLEMENTATION Each introduction of new configuration option touches all the above files. Each upgrade should override the database options, even if user had not modified the defaults. It is very difficult to add misc internal configurations to override built-in constants, as the implication of adding these effect much larger scope (see above). NEW IMPLEMENTATION 1. Store only non default values within vdc_options. 2. Support version override within vdc_options, so that the lookup will be first to specific version, and if absent checkout the general. 3. Provide defaults, types, validation hint within properties files, provided within the binary distribution (jar). 4. Codegen enum or simple constants out of the configuration defaults during build to allow type safe build. a. there can be multiple properties file, maintainers should be able to choose location of configuration. b. simple constants are easier to manage as we can generate class per property file without the need to aggregate. c. the configuration subsystem should read the properties file, not use the codegen output. 5. Generate combined property files for engine-config usage. 6. Modify the engine-config utility: a. use new property file format. b. add option "revert to default", simply remove entries. c. add option "drop unused" to drop all options that are not within the defaults. 7. Support program provided defaults, something like Config.get("MYCONFIG", default), so that developers can replace all internal constants with potentially configurable scheme. Attached a prototype of conversion program to be run at devenv and generate the suggested new format of defaults out of existing sources. BENEFIT IN NEW IMPLEMENTATION No more database update when changing application's default. Reduce the chance of sync lost between multiple artifacts that describes the same entity. Reduce merge conflict when competing on same files. Support developer's defaults override, enable easier support.