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