cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-1052) security_group.py broken add_network_rules() exception handling hides all errors
Date Thu, 14 Mar 2013 19:42:14 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13602622#comment-13602622
] 

ASF subversion and git services commented on CLOUDSTACK-1052:
-------------------------------------------------------------

Commit beb6170d2a5994edc2524c74751e7cf44843e98b in branch refs/heads/4.1 from Chip Childers
<chip.childers@gmail.com>
[ https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;h=beb6170 ]

Summary: Fix exception handling in security_group.py

Detail: Code was attempting to concatinate an exception to a string.
Updated to convert to text and concatinate that.

BUG-ID: CLOUDSTACK-1052
Bugfix-for: master
Reported-by: Noa Resare
Signed-off-by: John Kinsella <jlk@stratosec.co> 1363218769 -0700

                
> security_group.py broken add_network_rules() exception handling hides all errors
> --------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-1052
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1052
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>            Reporter: Noa Resare
>            Assignee: John Kinsella
>            Priority: Minor
>
> Line 695 in version 6f29317 of security_group.py hides all possible errors in the add_network_rules()
function due to a unfortunate attempt to concatenate a str with type.
> In principle one could have lots of objections to that code. Why only log on debug level
debug, when there was an unexpected error? The english in the error message doesn't really
parse. 
> Personally I would prefer removing it altogether. If we want to log all exceptions via
the logging framework instead of leaving that responsibility to the caller a generic catch
all in the last block of the file that logs everything that no one else catches properly would
be a better option.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message