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:

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.