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): ruby193-rubygem-staypuft-0.1.22-1.el6ost.noarch How reproducible: 100% ** 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: ActiveRecord::StatementInvalid 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'
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.
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.
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.
*** Bug 1127864 has been marked as a duplicate of this bug. ***
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.
https://github.com/theforeman/staypuft/pull/260
merged
Verified: rhel-osp-installer-0.1.9-1.el6ost.noarch The described issue doesn't reproduce.
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/RHBA-2014-1090.html