Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1103151

Summary: Using the default 'http://' RHEL repo path results in kickstart not found errors during deployment.
Product: Red Hat OpenStack Reporter: Lee Yarwood <lyarwood>
Component: rubygem-staypuftAssignee: Marek Hulan <mhulan>
Status: CLOSED ERRATA QA Contact: Omri Hochman <ohochman>
Severity: medium Docs Contact:
Priority: high    
Version: 4.0CC: aberezin, ddomingo, mburns, mhulan, sasha, sclewis, sgordon
Target Milestone: ga   
Target Release: 5.0 (RHEL 7)   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: foreman-installer-staypuft-0.0.18-1.el6ost Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-04 18:32:30 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:
Attachments:
Description Flags
Screenshot of the KS error.
none
production.log trace with debug on. none

Description Lee Yarwood 2014-05-30 11:36:18 UTC
Description of problem:
Using the default 'http://' RHEL repo path results in kickstart not found errors during deployment. If possible it would be good to force a valid URI to be entered before leaving the configuration screen to ensure this will work later on when generating the deployment ks scripts.

Version-Release number of selected component (if applicable):
# rpm -qa | grep staypuft
foreman-installer-staypuft-0.0.13-2.el6ost.noarch
ruby193-rubygem-staypuft-0.0.16-1.el6ost.noarch

How reproducible:
Always

Steps to Reproduce:
1. Leave the RHEL repo path as http:// during the configuration step.
2. Later, attempt to provision an environment.
3. All hosts fail to find the KS files, foreman lists a bad URI error in production.log.

Actual results:
Unintuitive error displayed while attempting to kickstart a host.

Expected results:
Bad URI is caught during the configuration step, forcing the user to enter a valid path before continuing.

Additional info:

Comment 1 Lee Yarwood 2014-05-30 11:37:16 UTC
Created attachment 900771 [details]
Screenshot of the KS error.

Comment 2 Lee Yarwood 2014-05-30 11:38:13 UTC
Created attachment 900772 [details]
production.log trace with debug on.

Comment 4 Marek Hulan 2014-06-16 15:33:26 UTC
This is fixed in upstream since 0.0.18

Comment 6 Alexander Chuzhoy 2014-06-20 15:00:33 UTC
Verified: FailedQA
Failed QA with foreman-installer-staypuft-0.0.18-1.el6ost.noarch

Was able to start a deployment using the default 'http://' RHEL repo path.

The deployment got stuck on 15% deploying the controller.
The message on the console is:
Could not find kernel image: boot/RedHat-<release>-<arch>-vmlinuz

Comment 7 Alexander Chuzhoy 2014-06-20 19:20:25 UTC
Verified: FailedQA
Failed QA with foreman-installer-staypuft-0.0.20-1.el6ost.noarch

Was able to start a deployment using the default 'http://' RHEL repo path.

The deployment got stuck on 15% deploying the controller.
The message on the console is:
Could not find kernel image: boot/RedHat-<release>-<arch>-vmlinuz

Comment 8 Marek Hulan 2014-06-23 06:16:07 UTC
Did you rerun the installer? How did you set the 'http://' value?

Comment 9 Alexander Chuzhoy 2014-06-23 13:28:24 UTC
I ran the staypuft-installer.
'http://' is the default value.
After re-producing this bug, I configured another RHEL repo path and everything worked.

Comment 10 Alexander Chuzhoy 2014-06-23 15:45:36 UTC
So we see the following code added to /usr/share/foreman-installer/hooks/lib/subscription_seeder.rb:

  def repo_path_invalid?
    URI.parse(@repo_path)
    return false
  rescue URI::InvalidURIError => e
    @logger.debug "User tried to use invalid repo path: #{e.message}"
    return true
  end

And the following message is added to the log (/var/log/foreman-installer/foreman-installer.log):
[DEBUG 2014-06-20 16:37:04 main] User tried to use invalid repo path: bad URI(absolute but no path): http://

However, this isn't enough. The deployment should be prevented from starting - it will fail anyway.

Thanks.

Comment 11 Marek Hulan 2014-06-25 10:30:57 UTC
I've extracted repo path to separate menu. User can still skip that but there's warning and explanation. User input is validated in case he does not skip it. They can then skip subscription manager configuration. As we discussed yesterday on IRC, I'd recommend opening a new RFE for adding validation to staypuft webui that wouldn't allow running deployment if repo path is not set (or valid or reachable?). But I think this bug can be considered as fixed. The patch is in staypuft-installer 0.0.24 hence I'm moving to POST.

Comment 12 Mike Burns 2014-06-25 13:17:12 UTC
*** Bug 1113111 has been marked as a duplicate of this bug. ***

Comment 13 Stephen Gordon 2014-06-25 13:44:29 UTC
I'm not clear that this is a dupe, the behaviour introduced here is that I now *must* enter a URL, which is what I was complaining about in Bug # 1113111 because it's unclear to me what that URL is meant to be.

The text needs to be more explanatory and / or provide a sensible default.

Comment 14 Mike Burns 2014-06-25 20:37:49 UTC
sorry, didn't mean to clean needinfo.

Can you look with the new rhel-osp-installer in this build?  we do allow you to skip setting it and I think we have more of an explanation there.  If you think we need more, please reopen.

Comment 15 Alexander Chuzhoy 2014-06-30 18:34:40 UTC
Verified:rhel-osp-installer-0.0.25-5.el6ost.noarch

During the execution of rhel-osp-installer you're prompted to configure the installation media and you're warned woth the following message:

"Now you should configure installation media which will be used for provisioning.
Note that if you don't configure it properly, host provisioning won't work until you configure installation media manually."


Note: You're able to complete the installation with the default RHEL repo path (http://).

The field verification during employment will be verified as part of this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1112866

Comment 18 errata-xmlrpc 2014-08-04 18:32:30 UTC
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.

http://rhn.redhat.com/errata/RHEA-2014-1003.html