Description of problem: Currently, there is no way to find out whether a user changed the default values in vdc_options using engine-config. Having such tool would allow users to see what was changed and might be overridden when upgrading Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(In reply to Benny Zlotnik from comment #0) > Description of problem: > Currently, there is no way to find out whether a user changed the default > values in vdc_options using engine-config. > > Having such tool would allow users to see what was changed and might be > overridden when upgrading I think this is a bit vague, please be more specific. E.g.: 1. If a value is changed by engine-setup, how do you want to treat that? Is this a user-change? And if it's as a result of asking the user something? Or is affected by the answerfile the user provided? 2. Same as above, but for the engine itself. Not sure it ever changes vdc_options, but it can. And even if it does not, now, it might in future versions. 3. Some values are intended "for internal use" and might needlessly confuse the user if displayed. E.g. "MinimalETLVersion". Should we show them? 4. If a value had a different default value between versions, I think you might be able to come up with two flows going through different setup/upgrade points, without changing anything manually with 'engine-config', but still have differences. If so, should these be displayed? One might claim that all such cases are bugs and should be fixed, but they can still happen. See bug 1582310 for a specific case (which we decided to not fix). If this bug is for a specific case, perhaps provide more details. Otherwise, please realize this isn't an easy question to answer, and for users that really care, it's probably better, at least IMHO, to setup a test system (or backup/restore/upgrade on a test system), and compare the outputs of 'engine-config -a' between the production and the test systems.
Thanks for the reply (In reply to Yedidyah Bar David from comment #1) > (In reply to Benny Zlotnik from comment #0) > > Description of problem: > > Currently, there is no way to find out whether a user changed the default > > values in vdc_options using engine-config. > > > > Having such tool would allow users to see what was changed and might be > > overridden when upgrading > > I think this is a bit vague, please be more specific. E.g.: > > 1. If a value is changed by engine-setup, how do you want to treat that? Is > this a user-change? And if it's as a result of asking the user something? Or > is affected by the answerfile the user provided? Since we have no way to distinguish changes made manually by users from ones that are made by engine-setup/something similar, we will have to show those as well. We are aware of such "false positives" and feel it's still good enough > 2. Same as above, but for the engine itself. Not sure it ever changes > vdc_options, but it can. And even if it does not, now, it might in future > versions. Same as above > 3. Some values are intended "for internal use" and might needlessly confuse > the user if displayed. E.g. "MinimalETLVersion". Should we show them? Same as above, I am not aware of a way to tell something is internal > 4. If a value had a different default value between versions, I think you > might be able to come up with two flows going through different > setup/upgrade points, without changing anything manually with > 'engine-config', but still have differences. If so, should these be > displayed? One might claim that all such cases are bugs and should be fixed, > but they can still happen. See bug 1582310 for a specific case (which we > decided to not fix). Not entirely sure I understand, but it will show all changes made for every version, we are ok with this > If this bug is for a specific case, perhaps provide more details. Otherwise, > please realize this isn't an easy question to answer, and for users that > really care, it's probably better, at least IMHO, to setup a test system (or > backup/restore/upgrade on a test system), and compare the outputs of > 'engine-config -a' between the production and the test systems. We had requests for something like this from support and QE, I don't have all the links at the moment (maybe Dan can add them) But I did find an old RFE (https://bugzilla.redhat.com/show_bug.cgi?id=1169090), while this tool doesn't really do what's asked in the RFE it does provide a way to make it easier. Our solution automates the setup of a test system (well, it only creates the database, so it's still not ideal but still useful)
Removing from 4.2, I really don't like the idea of creating another database for checking what fields changes. I don't really understand why this is really needed, but if we really needed, then it should probably be part of engine-config.
(In reply to Martin Perina from comment #3) > Removing from 4.2, I really don't like the idea of creating another database > for checking what fields changes. I don't really understand why this is > really needed, but if we really needed, then it should probably be part of > engine-config. Hi, As stated before, we have support engineers who requested this and QE as well. The tool is a standalone tool and only runs if asked for explicitly. The database is created and used only during the runtime of the script, it is removed once it's finished. It won't bother anyone who does not wish to use it
discussed briefly with Martin offline - why not just add a new field "default_value" to vdc_options table to hold the defaults and trivially modify engine-config tool to show it and/or another tool to report discrepancies? Looks like a much cleaner implementation without messing with internal db scripts. This should be doable in a zstream
Hi Moti, We discussed this option of adding another field but found it not good enough, do you by any chance remember why?
(In reply to Benny Zlotnik from comment #6) > Hi Moti, > > We discussed this option of adding another field but found it not good > enough, do you by any chance remember why? IIRC, the issue with keeping the default value aside is what happens when the default value is being changed between versions. Also, how do you obtain the actual default value ? in 4.1 we'd might have a specific set of default value and in 4.2 it might be a different set. If we decide on having an extra field for the default value, the documentation should state that the discrepancies tool checks for differences from the default value of a specific version only, and not from the first default value that was originally introduced (since we don't track the history of the default values). In that case, running that tool will produce a different output for the same engine configuration values based on the version it is run against.
The other cons in adding the extra field: 1. Will not work for older version, especially those that are relevant for most of the target users 2. Introduces more complexity and risk than a standalone script If we're okay with these issues then I'll go ahead with the new plan Martin, please advise
(In reply to Benny Zlotnik from comment #8) > The other cons in adding the extra field: > 1. Will not work for older version, especially those that are relevant for > most of the target users > 2. Introduces more complexity and risk than a standalone script > > If we're okay with these issues then I'll go ahead with the new plan > Martin, please advise Switching to offline discussion, so clearing the needinfo
Verified in ovirt-engine-4.2.8.2-0.1.el7ev.noarch Changes right after the engine installation, i.e., changes that have been specified during the engine-setup: --~-- # engine-config --diff Name: WebSocketProxy Version: general Current: engine.example.com:6100 Default: Off Name: ImageProxyAddress Version: general Current: engine.example.com:54323 Default: localhost:54323 --~-- Let's make some more changes: --~-- # engine-config -s ClusterEmulatedMachines=rhel6.3.0 --cver=3.0 # engine-config -s UserSessionTimeOutInterval=600 # engine-config --diff Name: UserSessionTimeOutInterval Version: general Current: 600 Default: 30 Name: WebSocketProxy Version: general Current: engine.example.com:6100 Default: Off Name: ImageProxyAddress Version: general Current: engine.example.com:54323 Default: localhost:54323 Name: ClusterEmulatedMachines Version: 3.0 Current: rhel6.3.0 Default: rhel6.2.0 --~-- Now rollback one change and see the diff: --~-- # engine-config -s ClusterEmulatedMachines=rhel6.2.0 --cver=3.0 # engine-config --diff Name: UserSessionTimeOutInterval Version: general Current: 600 Default: 30 Name: WebSocketProxy Version: general Current: engine.example.com:6100 Default: Off Name: ImageProxyAddress Version: general Current: engine.example.com:54323 Default: localhost:54323 --~--
This bugzilla is included in oVirt 4.2.8 release, published on January 22nd 2019. Since the problem described in this bug report should be resolved in oVirt 4.2.8 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.