Description of problem: If a user attempts to provision a virtualized guest via the Satellite WebUI and sets it to link to a nonexistent virt network bridge, the attempt will fail, resulting in an intriguing Koan traceback, which is attached to this bug. Since, without further configuration, virtual bridge information is inherited from a kickstart profile, this could prove confusing to a user. Version-Release number of selected component (if applicable): 530, 5/29 build How reproducible: Always Steps to Reproduce: 1. SDC->Virtualization->Provisioning 2. Select a profile to be provisioned 3. Click 'Advanced Options' 4. Select a nonexistent virtual bridge 5. Run rhn_check upon the client system Actual results: Traceback as attached Expected results: Error in the WebUI stating that virtual bridge is nonexistent Additional info:
Cliff and I *think* this isn't too hard to capture and return back up, so we're approving. If the effort is large, then throw it back to triage for reconsideration.
Master commit 56f08c2422cd9d06f7def90f20c70e26666dd9aa tree cdad89cd3215165c5c013f419edcfbc5ce63a149 Vader commit a29d0fa0890c283c8b881ce4d12d31223e987f44 tree 2669e4c85681a155e610e52659ceb319e686402a client/tools/spacewalk-koan/spacewalkkoan/spacewalkkoan.py Added some information on the error message to the status returned to the server. It would be really ugly to parse for a specific error condition, such as the broken bridge in this case. Devan and I talked about it and the best compromise is to include the exception's error message in the result sent back to the server. This covers the generic case as well, which should generally give the user some more information in the UI about why it failed. For verification, check the details section of the event after it has completed. It should begin with a message about not being able to find the bridge.
VERIFIED on 6/12 build.
message in error when vrbx does not exist release pending
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1434.html