Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1418085 - An unplanned outage of the fusor system can cause inconsistent information to appear concerning a deployment that was running at the time.
Summary: An unplanned outage of the fusor system can cause inconsistent information to...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Quickstart Cloud Installer
Classification: Red Hat
Component: WebUI
Version: 1.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: John Matthews
QA Contact: Sudhir Mallamprabhakara
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-31 19:27 UTC by James Olin Oden
Modified: 2017-02-01 14:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description James Olin Oden 2017-01-31 19:27:50 UTC
Description of problem:
I was doing a deployment in a nested virt. environment, destroyed the fusor VM and restarted it.  Once it was restarted I went back to the UI and in the deployments screen it said the deployment was in error, however if you clicked on the deployment it looked like it was in progress and had no issues.  Clicking on the details tab showed that the main task was in error.

The power was not recycled till it was past the sync portion of the 
deployment.

Version-Release number of selected component (if applicable):
QCI-1.1-RHEL-7-20170130.t.0

How reproducible:
Only tried it once.

Steps to Reproduce:
1. Start a deployment. 
2. Reboot the fusor machine while the deployment is going.
3. Examine the deployments page, and the progress overview page and 
   the progress overview details page.

Actual results:
The different pages will report results that are inconsistent with one another.

Expected results:
consistent reporting of the state of the deployment.

Comment 1 John Matthews 2017-02-01 14:48:31 UTC
The issue as I understand it is..

WebUI has it's own state, it assumes that after it has retrieved data from the REST API that data will be valid.  

Problem here is that WebUI retrieved data, then the backend REST API was destroyed and recreated so it's at a fresh spot...no deployment running yet webui doesn't know that and displays like a task is still running.

Could look into adding better error detection so when polling if the state has changed, tasks don't exist, etc the wizard flow detects this and notifies user.


Note You need to log in before you can comment on or make changes to this bug.