Bug 1293410 - [RFE] Enable selective running of contents
[RFE] Enable selective running of contents
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: preupgrade-assistant (Show other bugs)
6.7
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Petr Hracek
Tereza Cerna
: Extras, FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-21 12:18 EST by Alois Mahdal
Modified: 2016-05-11 04:26 EDT (History)
6 users (show)

See Also:
Fixed In Version: preupgrade-assistant-2.1.5-1.el6
Doc Type: Enhancement
Doc Text:
Selective Rule Execution Two new options have been added to preupgrade-assistant. They are "--select-rules" and "--list-rules". * "--select-rules" will run a set of contents given as a comma-separated list. The order of execution is still decided by OpenSCAP, i.e. lexical IIUC. * "--list-rules" will list the available contents.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-11 04:26:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alois Mahdal 2015-12-21 12:18:01 EST
Background
==========

In some cases, achieving a decent coverage for a content means re-running
the check script multiple times.  Currently we have tests requiring tens
of re-runs but are planning more demanding tests, e.g. with hundreds
of re-runs.

With the whole assessment potentially taking as much as 15-30 minutes,
it is extremely inefficient to run whole assessment each time.


Problem
=======

Currently we're able to run single content (or group) by deleting contents
that we don't want to run.  Needless to say, this is dangerous, ugly,
complicated[1], fragile and incorrect.

  [1]: turns out that selecting proper set of 'leaves' from the content
       tree is not a trivial task, especially not in Bash

Being able to run just selected set of contents would be much less wrong,


Suggestion
==========

Add necessary developer mode option(s) to enable following scenarios:

 *  (A) run a single content,

 *  (B) run contents selected by wildcard or regular expression,

 *  (C) run an ordered set of contents,

 *  (D) enumerate contents from upgrade path.

TBD: decide how to identify content: path (relative?) or XCCDF ID


Breakdown
=========

(A) Is currently the most needed case for reasons explained above.

(B) Would be useful e.g in case of "soname"-related contents that need
to be run together.

(C) Would enable: testing with regards of proper content separation,
i.e. to increase confidence that ordering is not significant.

(D) would be necessary to support case (C) (enumerate, shuffle, run).
It would also help avoiding hard-coding content names in some cases of
(B) and (A), thus increasing maintainability of test code.
Comment 2 Petr Hracek 2016-01-04 06:02:16 EST
This RFE is done by upstream commit https://github.com/phracek/preupgrade-assistant/commit/276b42aba3d74d79ea1086ee9b96105e1a68900c

Some more explanation.
A) The commit is able to execute a single content

B) This is a pretty complicated from python point of view we should detect a wildcard or regular expression and I don't see a benefit for it. Implementation takes a pretty much time. I suggest to not implement it.

C) This depends on OpenSCAP. Nowadays it is ordered by alphanumeric. Implementing of this feature means update INI scripts creates a new API, correct XML files and another things.
I guess, from development point of view, that implementation does not bring so enhancement as we can expect it.

D) This is covered by the commit
Comment 3 Alois Mahdal 2016-01-04 11:35:53 EST
We've agreed on implementation with Petr.

The new preupg will have two new options:

 *  --select-rules - run a set of contents given as a comma-separated list.
    Order is still decided by OpenSCAP, i.e. lexical IIUC.

 *  --list-rules - List available contents.

In both cases, the format of content item is the "xccdf_ ID", so the output of listing can be easily re-used in the other argument.

With this, (A) and (D) are fulfilled right away, we can quite easily achieve (B) by doing the filtering in the test code.  (C) is covered by --select-rules *except* for the ordering significance, but as Petr has explained, that would require intervention with OpenSCAP, which would be too hard and risky, i.e. not worth (at least for now).
Comment 7 Alois Mahdal 2016-01-29 03:28:28 EST
The listing works, except that it seems to actually start assessment, i.e. it

 *  asks for confirmation,
 *  runs the "generation of common files"
 *  then lists the rules.

Furthermore, it still outputs all to STDOUT, so the list is not really correct and re-usable for --select-rules.

Example output (stripped the ^H sequences etc.):


    The Preupgrade Assistant is a diagnostics tool 
    and does not perform the actual upgrade.

    Do you want to continue? y/n
    Gathering logs used by preupgrade assistant:
    All installed packages                                 : 01/10 finished (time 00:00s)
    All changed files                                      : 02/10 finished (time 00:37s)
    Changed config files                                   : 03/10 finished (time 00:00s)
    All users                                              : 04/10 finished (time 00:00s)
    All groups                                             : 05/10 finished (time 00:00s)
    Service statuses                                       : 06/10 finished (time 00:00s)
    All installed files                                    : 07/10 finished (time 00:01s)
    All local files                                        : 08/10 finished (time 00:00s)
    All executable files                                   : 09/10 finished (time 00:00s)
    RedHat signed packages                                 : 10/10 finished (time 00:00s)
    List of all available rules:
    xccdf_preupg_rule_drivers_ObsoletedNetworkDrivers_obsoletedNetworkDrivers
    xccdf_preupg_rule_storage_multipath_check
    xccdf_preupg_rule_networking_arptables_jf_removedoptions
    xccdf_preupg_rule_packages_ObsoletedW3m_obsoletedw3m
    xccdf_preupg_rule_system_SonameKept_SonameKept
    [...]
    xccdf_preupg_rule_system_hal_check_script
    xccdf_preupg_rule_backup_NoverifyConfigs_noverifycfg
    xccdf_preupg_rule_desktop_GNOME_gnome
    xccdf_preupg_rule_services_cupsbrowsing_cupsbrowsing
Comment 8 Alois Mahdal 2016-01-29 03:30:48 EST
Above comment relates to

preupgrade-assistant-2.1.4-6.el6.noarch
Comment 9 Petr Hracek 2016-01-29 09:01:51 EST
I see it. Ok, I will correct it. Hopefully soon.

I thought about it, but it seems that I completely forgot on it.
I have to clarify it if root account is not need. But generation of common logs is really weird for this case.
Thanks.
Comment 10 Petr Hracek 2016-01-29 09:31:45 EST
I see the point why I did it by this approach.
Before gathering common logs I don't have any input like what modules we have.

Preupgrade-assistant collect these information by themself. Over class ComposeXML.

One approach can be go through all directories and append xccdf_preupg_rule prefix.

Another approach can be to create a global XML file temporarily.
I would prefer first one.
Comment 11 Alois Mahdal 2016-01-31 15:21:39 EST
(In reply to Petr Hracek from comment #10)
[...]
> One approach can be go through all directories and append xccdf_preupg_rule
> prefix.

I tried to do something similar but it turned out that when deployed, it's not easy at all to determine what is a module and what isn't.  For example, in

    mysql/general_changes
    mysql/configuration_changes
    mysql
    mysql/data_migration

mysql is not a module, but both have group.xml file.  I ended up writing "all childless nodes" function which (in my Bashese) was really ugly.  The point I'm trying to make, if you can reliably detect what's a module and what isn't, that would be nice.

But other ways that come to my mind:

We could keep the .ini files, thus making the detection (relatively) easy and reliable,

or

we could even create the list compile-time and keep it somewhere, then just spit it out.  Yeah, I know, it sounds like cheating ;)

On the other hand, from my POV the fact that we need to run the "common" part just to be able to list modules is ... yeah, a bit lame ... but bearable, given that it would be reliable and stdout/stderr separation would be right.
Comment 12 Petr Hracek 2016-02-01 12:40:30 EST
This is fixed by commit https://github.com/phracek/preupgrade-assistant/commit/507f50b575c939590bf0e9e5e620011b02c287a4

During content generation preupg-xccdf-compose creates a file list_rules in directory /usr/share/preupgrade/RHEL6_7.
Comment 18 errata-xmlrpc 2016-05-11 04:26:42 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.

https://rhn.redhat.com/errata/RHBA-2016-1022.html

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