Bug 503996 - Provisioning a virtualized guest which is set to link to a nonexistent virt network bridge results in a traceback
Provisioning a virtualized guest which is set to link to a nonexistent virt n...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Virtualization (Show other bugs)
530
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Dobies
Steve Salevan
:
Depends On:
Blocks: 457075
  Show dependency treegraph
 
Reported: 2009-06-03 13:58 EDT by Steve Salevan
Modified: 2009-09-10 15:26 EDT (History)
2 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-10 15:26:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steve Salevan 2009-06-03 13:58:10 EDT
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:
Comment 2 Brandon Perkins 2009-06-04 12:37:19 EDT
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.
Comment 3 Jay Dobies 2009-06-09 11:15:29 EDT
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.
Comment 4 Steve Salevan 2009-06-17 16:37:51 EDT
VERIFIED on 6/12 build.
Comment 5 wes hayutin 2009-08-06 17:25:42 EDT
message in error when vrbx does not exist
release pending
Comment 6 Brandon Perkins 2009-09-10 15:26:08 EDT
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

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