Bug 1293410
| Summary: | [RFE] Enable selective running of contents | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Alois Mahdal <amahdal> |
| Component: | preupgrade-assistant | Assignee: | Petr Hracek <phracek> |
| Status: | CLOSED ERRATA | QA Contact: | Tereza Cerna <tcerna> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.7 | CC: | fkluknav, mflitter, ovasik, phracek, pstodulk, ttomecek |
| Target Milestone: | rc | Keywords: | Extras, FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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 08:26:42 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 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).
The messages have updated based on your https://bugzilla.redhat.com/show_bug.cgi?id=1293410#c3 Relevant commit is https://github.com/phracek/preupgrade-assistant/commit/b2005c6381485d76b8de2b9c66c9de52aa41c356 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
Above comment relates to preupgrade-assistant-2.1.4-6.el6.noarch 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. 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. (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. 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. 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 |
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.