Description of problem:

This is actually probably multiple bugs all tied together -- and perhaps an edge case -- but it was painful to try and sort through.

In certain (?) circumstances, errors thrown by the backend are not bubbling up to the UI when trying to provision a system. In this situation, the user is left completely in the lurch as to what has taken place.

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


How reproducible:
I'm not 100% sure of a repro case, although I think in this situation we were trying to provision on a system that mysteriously had virt support turned off. We'll make that assumption here.

Steps to Reproduce:
1.  Attempt to provision a system which causes an error similar to that seen in the results below. You may be able to do this by running product on a system which has virt flags disabled.
2.  Observe results.


Actual results:
Several things actually.

* Error like the one below does not bubble up to UI.
Rolling back due to a problem: [Settings up compute instance whynow.example.org  1       failed  [#<Host::Managed id: nil, name: "whynow.example.org", ip: "192.168.100.13", environment: nil, last_compile: nil, last_freshcheck: nil, last_report: nil, updated_at: nil, source_file_id: nil, created_at: nil, mac: nil, root_pass: nil, serial: nil, puppet_status: 0, domain_id: 1, architecture_id: 1, operatingsystem_id: 1, environment_id: 9, subnet_id: 1, ptable_id: 1, medium_id: 5, build: true, comment: "", disk: "", installed_at: nil, model_id: nil, hostgroup_id: 1, owner_id: 1, owner_type: "User", enabled: true, puppet_ca_proxy_id: nil, managed: true, use_image: nil, image_file: nil, uuid: nil, compute_resource_id: 1, puppet_proxy_id: 1, certname: nil, image_id: nil, organization_id: 1, location_id: nil, type: "Host::Managed">, :setCompute]]

* Page is reloaded and user is blindly taken back to virt machine editing page.

* Virt machine is left half-baked, and while no new hosts show up in Hosts view, machines can no longer be created with the name(s) used in other futile attempts.  For example, per the logs above, user can no longer try and create a system called "whynow" -- presumably because a basic storage device is listed in libvirt's storage directory -- but no such name appears in UI.

Expected results:
If we fail, we fail and we tell user
If we fail, we don't consume namespace -- hostnames can be reused if a failure to create host occurs.

Additional info: