Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1330762

Summary: "valid scenario" message is not useful
Product: Red Hat Enterprise Linux 6 Reporter: Alois Mahdal <amahdal>
Component: preupgrade-assistantAssignee: Petr Hracek <phracek>
Status: CLOSED WONTFIX QA Contact: Alois Mahdal <amahdal>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.8CC: fkluknav, jmazanek, mbocek, phracek, pstodulk, ttomecek
Target Milestone: rcKeywords: Extras
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-05-03 12:58:59 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:

Description Alois Mahdal 2016-04-26 21:49:49 UTC
Description of problem
======================

preupg-xccdf-compose and preupg-content-creator refuse most paths but are
not helpful about what they don't like about them.  For example, I have
created a sample tree by copying RHEL6_7 and removing almost anything:

    $ tree APIX
    APIX
    └── main
        ├── group.ini
        └── nativity
            ├── module.ini
            ├── run.sh
            └── solution.txt

    2 directories, 4 files
    $

and fed it to preupg-xccdf-compose:

    # preupg-xccdf-compose APIX
    Use valid scenario like RHEL6_7 or CENTOS6_RHEL6
    #

preupg-content-creator is no more helpful:

    # preupg-content-creator
    Specify a upgrade path (like RHEL6_7) where a content will be stored: APIX
    Scenario 'None' is not valid.
    It has to be like RHEL6_7 or CentOS7_RHEL7.
    #


Version-Release number of selected component
============================================

preupgrade-assistant-2.1.6-2.el6


Additional info
===============

Turns out that paths like fooN_N seem to work, where N must be integers.

Frankly the restriction seems artificial;  I have no idea why there
should be such requirement This just limits usability of the tool.

Comment 2 Petr Hracek 2016-04-27 12:53:06 UTC
Tests are completely missing.
Thanks for this report, though.

I will investigate it soon.

Comment 3 Alois Mahdal 2016-05-04 04:05:38 UTC
I'm not sure I understood your last comment;  but just a heads-up: if you agree with my last 2 paragraphs in comment 0, there's an easy way out:  just drop the restriction and you don't have to care about message ;)

That solution would be easy *and* make QA happier.

The reason it matters is that we will need to create mock upgrade paths for various reasons (mostly p-a API testing; it's quite possible that there will be 1 path for each test), and having to name things this way makes it harder to name them usefully.

Comment 5 Alois Mahdal 2017-04-04 20:39:36 UTC
Umm, I have acked this but then noticed the following bug is also in tracker:

 -  Bug 1381198 ("[RFE] Let's get rid of upgrade path from module directory name')

If the RFE is going to be implemented (I heard it's already in upstream), then this bug will become mostly irrelevant.

Comment 6 Michal Bocek 2017-05-03 12:58:59 UTC
Bug 1381198 is going to be implemented. The progress will be tracked in that one so I'm closing this one as a duplicate.

*** This bug has been marked as a duplicate of bug 1381198 ***

Comment 7 Michal Bocek 2017-05-04 10:46:31 UTC
This bug was about making the error messages more comprehensible. Because the requirement of specific module set directory name will be dropped per Bug 1381198, this bug is not going to be fixed. The unhelpful messages will be removed completely.