Bug 1279032 - mysql/configuration_changes: has set requirements incorectly
mysql/configuration_changes: has set requirements incorectly
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: preupgrade-assistant-el6toel7 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: pstodulk
Alois Mahdal
: Extras
Depends On:
  Show dependency treegraph
Reported: 2015-11-07 05:25 EST by Alois Mahdal
Modified: 2016-05-11 04:28 EDT (History)
4 users (show)

See Also:
Fixed In Version: preupgrade-assistant-el6toel7-0.6.44-1.el6
Doc Type: Bug Fix
Doc Text:
Previously, Preupgrade Assistant could incorrectly report upgrade risk based on configuration files even if the relevant package was already uninstalled from the system. After this fix, Preupgrade Assistant will only report risks relevant to installed packages.
Story Points: ---
Clone Of:
Last Closed: 2016-05-11 04:28:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alois Mahdal 2015-11-07 05:25:04 EST
Description of problem

`databases/mysql/configuration_changes` can show false positives as it
will perform its checks even if the relevant package is not installed.

Version-Release number of selected component


How reproducible


Steps to Reproduce

 1. Uninstall mysql-server
 2. Add one or more deprecated options ot /etc/my.cnf
 3. run preupg

Actual results

Risk is reported and content result is `needs_action`

Expected results

No risk is be reported and content result is `notapplicable`
Comment 2 pstodulk 2016-02-18 11:38:26 EST
Rpm mysql-server isn't priority of this content. Configuration files are under rpm mysql-lib. However, content requires installed mysql due to binary:

But mysql-libs are required by other packages too. So, I recommend set applies_to for mysql-libs and inside check script check if mysql is installed. When mysql isn't installed, we should probably print some info with *_risk, that content can't check configuration files and ask for installation of mysql rpm first.

What do you thinkg Lojzo about that solution?
Comment 3 Alois Mahdal 2016-02-18 17:33:47 EST
Seems OK to me.

What kinda sucks is that in case mysql-libs are present but the binary isn't, we'll have to blackmail user (into installing the server which we'll be migrating then) ... but I don't see any better solution.

We might want to think about generic solution to such situation (dependency X needed to analyze files of Y) but for this bug the above seems OK.
Comment 4 pstodulk 2016-02-19 04:36:07 EST
(In reply to Alois Mahdal from comment #3)
> We might want to think about generic solution to such situation (dependency
> X needed to analyze files of Y) but for this bug the above seems OK.

I agree. We have now something like that - in INI files we can use "binary_req" or "requires" I don't like the output here. It's too generic:

,,INPLACERISK: HIGH: Binary /usr/bin/my_print_defaults is not installed"

I'll discuss it with Peter, if it is possible change the default message or append specific description for each content.
Comment 5 pstodulk 2016-02-19 10:26:50 EST
Ok. So we will use more general solution. binary_req in INI file will be set and better message will be provided by preupgrade-assistant.
Comment 6 pstodulk 2016-02-28 16:15:07 EST
After discussion, there is set requirements on mysql package which provides the binary (above) instead of binary_req.

That's because we want to rather print package which should be installed instead of binary.
Comment 10 Alois Mahdal 2016-04-29 16:22:30 EDT
Tested with preupgrade-assistant-el6toel7-0.6.48-1.el6:

 *  If mysql is missing, followint two risks are logged:

        INPLACERISK: HIGH: Package mysql is not installed.
        INPLACERISK: HIGH: Please, install all required packages (and binaries) and run preupg again to process check properly.

 *  Otherwise, risks along with relevant .cnf file are printed according to
    particular option used.  This is the "lagrest" variant (all problematic
    options in place):

        INPLACERISK: MEDIUM: /etc/my.cnf: option 'plugin-load=innodb=' is not supported
        INPLACERISK: HIGH: /etc/my.cnf: option 'innodb_file_io_threads' is not supported
        INPLACERISK: HIGH: /etc/my.cnf: option 'language' is deprecated
        INPLACERISK: HIGH: /etc/my.cnf: option 'log-bin-trust-routine-creators' was removed in MariaDB 5.5
        INPLACERISK: HIGH: /etc/my.cnf: option 'table_lock_wait_timeout' was removed in MariaDB 5.5

        The files mentioned above are backups of your original configuration files.
        After the upgrade you must manually replace the contents of the default
        MariaDB 5.5 configuration (as is appropriate to your environment), with the
        information provided about replaced or deprecated options listed in the
        backups.  You must restart MariaDB for these changes to take effect.
Comment 11 errata-xmlrpc 2016-05-11 04:28:04 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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