Bug 1127297 - staypuft: gui crash when we revisit setup wizard after adding hosts to deployment and try to change from HA to single controller
Summary: staypuft: gui crash when we revisit setup wizard after adding hosts to deploy...
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rubygem-staypuft
Version: 5.0 (RHEL 7)
Hardware: x86_64
OS: Linux
Target Milestone: ga
: Installer
Assignee: Scott Seago
QA Contact: Omri Hochman
: 1127864 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-06 14:48 UTC by Dafna Ron
Modified: 2014-08-21 18:08 UTC (History)
5 users (show)

Fixed In Version: ruby193-rubygem-staypuft-0.2.2-1.el6ost
Doc Type: Bug Fix
Doc Text:
When changing layout for a Deployment with hosts already added (i.e. non-HA to HA, Neutron to Nova networking, etc), any hostgroups that must be deleted to make the layout change will have any assigned hosts removed first. Changing from HA to non-HA (or vice versa) will delete the Controller hostgroup and create a new one. Changing from Neutron to Nova (or vice versa) will delete the Compute hostgroup (and Controller too for non-HA). Changing from Non-HA Neutron to HA or to Nova networking will delete the Neutron Network Node hostgroup.
Clone Of:
Last Closed: 2014-08-21 18:08:19 UTC

Attachments (Terms of Use)
screen shot (121.30 KB, image/png)
2014-08-06 14:48 UTC, Dafna Ron
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1090 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform Enhancement Advisory 2014-08-22 15:28:08 UTC

Description Dafna Ron 2014-08-06 14:48:53 UTC
Created attachment 924512 [details]
screen shot

Description of problem:

trying to change deployment from "High Availability Controllers / Compute " to " Controller / Compute " after we added hosts to the deployment (did not yet install, just assigned hosts) will cause gui to crash. 

PGError: ERROR: null value in column "hostgroup_id" violates not-null constraint : INSERT INTO "staypuft_deployment_role_hostgroups" ("created_at", "deploy_order", "deployment_id", "hostgroup_id", "role_id", "updated_at") VALUES ($1, $2, $3, $4, $5, $6) RETURNING "id"

Version-Release number of selected component (if applicable):


How reproducible:


** I am not sure if this would also happen if you initially select HA and than revisit and try to change - might be easier to reproduce in that way**

Steps to Reproduce:
1. create a new deployment and select a "Controller / Compute" 
2. add two hosts to the deployment 
3. press "revisit setup wizard
4. change to "High Availability Controllers / Compute" -> next
5. press "back" -> change to "Controller / Compute" 

Actual results:

from that time, every time you will try to change to Controller / Compute you will get a ui crash. 

Expected results:

we should be able to move back to single host 

Additional info:

This is the full trace: 

PGError: ERROR: null value in column "hostgroup_id" violates not-null constraint : INSERT INTO "staypuft_deployment_role_hostgroups" ("created_at", "deploy_order", "deployment_id", "hostgroup_id", "role_id", "updated_at") VALUES ($1, $2, $3, $4, $5, $6) RETURNING "id"
app/models/concerns/foreman/thread_session.rb:33:in `clear_thread'
lib/middleware/catch_json_parse_errors.rb:9:in `call'

Comment 1 Alexander Chuzhoy 2014-08-07 14:19:57 UTC
If this doesn't reproduce - need to "play" more with the deplpoyment. Attempt to modify it further. Was able to reproduce it on several setups.

Comment 2 Scott Seago 2014-08-07 15:38:06 UTC
Ahh, yes this is a case that I would expect to fail. Moving from HA to non-HA is, essentially, moving to a new layout (neutron to nova would do something similar). The issue is changing layout potentially adds and removes hostgroups. We probably need to disable those selections if any hosts are assigned.

Comment 3 Scott Seago 2014-08-07 15:51:06 UTC
The other thing we could do is explicitly unassign hosts before removing the hostgroup (if we're not attempting this already). We already attempt this on deployment destroy. The downside is if the user assigned hosts to the controller and then moved from HA to non-HA the hosts will no longer be assigned -- this might be confusing, and it might be easier to just prevent any layout changes after there are any hosts assigned.

Comment 4 Mike Burns 2014-08-08 14:19:21 UTC
*** Bug 1127864 has been marked as a duplicate of this bug. ***

Comment 5 Scott Seago 2014-08-08 16:21:12 UTC
Going to take the approach outlined in comment 3, not in comment 2

Some more background on what's going on:

So when we remove the Hostgroup/Depoyment mapping object, rails is configured to automatically delete the hostgroup. In this case, that hostgroup delete fails due to the presence of a host on it, but the rest of the operation proceeds normally (removing the mapping object) because of a bug in how Rails handles rollback in nested transactions. This rails-level bug is fixed in Rails 4.1, but we don't really need that fix -- that fix would prevent the data integrity issue here (dangling hostgroups), but the real fix is to remove hosts from the Hostgroup prior to attempting deletion here.

Comment 6 Scott Seago 2014-08-08 16:54:17 UTC

Comment 7 Scott Seago 2014-08-08 17:01:49 UTC

Comment 9 Alexander Chuzhoy 2014-08-11 20:36:44 UTC
Verified: rhel-osp-installer-0.1.9-1.el6ost.noarch

The described issue doesn't reproduce.

Comment 11 errata-xmlrpc 2014-08-21 18:08:19 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.


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