Bug 1284031

Summary: Deployment frozen on step 2A Detect Undercloud
Product: Red Hat Quickstart Cloud Installer Reporter: Antonin Pagac <apagac>
Component: Installation - RHELOSPAssignee: cchase
Status: CLOSED ERRATA QA Contact: Thom Carlin <tcarlin>
Severity: unspecified Docs Contact: Dan Macpherson <dmacpher>
Priority: unspecified    
Version: 1.0CC: bthurber, cchase, jmatthew, jmontleo, tcarlin, tsanders
Target Milestone: gaKeywords: Triaged
Target Release: 1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-13 16:23:00 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:
Bug Depends On:    
Bug Blocks: 1321046    
Attachments:
Description Flags
relevant part from production.log
none
relevant part from production.log for reproduced issue none

Description Antonin Pagac 2015-11-20 15:35:18 UTC
Created attachment 1097250 [details]
relevant part from production.log

Description of problem:
After deleting a previous failed RHCI+OSP deployment I created another one. I got up to step 2A Detect Undercloud, which informed me that the undercloud has been successfully detected (this was true for the previous deployment). However, upon clicking the Next button I'm left with "Loading..." and an error appears in production.log:

2015-11-20 10:13:39 [E] TypeError: can't convert nil into String

I can ping & ssh to the undercloud machine, also the Director UI is up and running. This is on bare metal hosts.

Version-Release number of selected component (if applicable):
RHCI-6.0-RHEL-7-20151118.t.0-RHCI-x86_64-dvd1.iso

How reproducible:
Happened to me once

Steps to Reproduce:
1. Create a deployment, detect undercloud, assign nodes
2. Delete the deployment, create another one
3. Click the Next button on step 2A Detect Undercloud

Actual results:
Deployment frozen with "Loading..." message

Expected results:
Undercloud gets detected, able to move to step 2B

Additional info:

Comment 1 Jason Montleon 2015-12-17 17:27:10 UTC
Can you try this please. There were various egon, UI, and selinux problems at various times that may have caused this that should be resolved.

Comment 2 Antonin Pagac 2016-01-11 08:43:15 UTC
Reproduced. Relevant part of production.log attached.

Version-Release number of selected component (if applicable):
RHCI-6.0-RHEL-7-20160107.t.1-RHCI-x86_64-dvd1.iso
RHCIOOO-7-RHEL-7-20151208.t.0-RHCIOOO-x86_64-dvd1.iso
Firefox 43.0.3

How reproducible:
Always

Steps to Reproduce:
1. Create a deployment, detect undercloud, assign nodes
2. Fill in all required information until you get to step 3 Subscriptions
3. Now exit and save the deployment
4. Go to RHCI Installer -> Deployments and delete the deployment you just created
5. Start a new RHELOSP deployment
6. Fill in all required information until you get to step 2A Detect Undercloud
7. Undercloud is already detected. The deployment won't ask you for the IP and login details.
8. Click Next

Actual results:
Deployment frozen on step 2A; UI completely frozen; traceback in production.log

Expected results:
RHCI should require detection of the Undercloud in all new deployments every time; after I input IP, login and password and Undercloud gets detected, I should be able to move to step 2B and continue the deployment

Workaround:
When I refresh the frozen page in Firefox, it then correctly asks for IP and login details and I'm able to continue the deployment

Comment 3 Antonin Pagac 2016-01-11 08:44:34 UTC
Created attachment 1113541 [details]
relevant part from production.log for reproduced issue

Comment 4 cchase 2016-06-03 13:53:45 UTC
This should be fixed in https://github.com/fusor/fusor/pull/899

The undercloud-deploy page should never show the undercloud is detected on a new deployment because a previous deployment had it.  It now allows you to enter in the undercloud information.

Comment 9 Thom Carlin 2016-07-26 19:21:43 UTC
Haven't seen this issue in QCI 1.0.  Moving to VERIFIED -- please reopen if it reoccurs

Comment 11 errata-xmlrpc 2016-09-13 16:23:00 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.

https://access.redhat.com/errata/RHEA-2016:1862