Activity log for bug #1452835

Date Who What changed Old value New value Message
2015-05-07 17:38:38 Hampapur Ajay bug added bug
2015-05-07 17:38:45 Hampapur Ajay juniperopenstack: assignee Hampapur Ajay (hajay)
2015-05-07 18:05:26 Hampapur Ajay description There is scope for improvements in exception handling in api-server and vnc-openstack extension in following areas: 1. Raise exceptions but defer handling(abort etc.) from bottom of call stacks to upper-layers giving them a chance to handle gracefully if possible. (e.g. vnc_cfg_ifmap.py:dbe_read should raise NoIdError but not transform into error-message. In update notification context it is a valid situation and can be handled gracefully) 2. There are patterns of ok, result = <some-callable>() if not ok: <error handling> This should be enhanced to also catch exceptions that can be handled gracefully vs not with appropriate error message in latter case. 3. Currently api-server returns human-readable strings on exceptions. Enhance to also append a json part that can be used in machine invocation contexts to generate exceptions on the remote end. 4. It would be good to send exception information (gracefully handled or otherwise) to collector. There is scope for improvements in exception handling in api-server and vnc-openstack extension in following areas: 1. Raise exceptions but defer handling(abort etc.) from bottom of call stacks to upper-layers giving them a chance to handle gracefully if possible. (e.g. vnc_cfg_ifmap.py:dbe_read should raise NoIdError but not transform into error-message. In update notification context it is a valid situation and can be handled gracefully) 2. There are patterns of       ok, result = <some-callable>()       if not ok:           <error handling>       This should be enhanced to also catch exceptions that can be handled gracefully vs not with appropriate error message in latter case. 3. Currently api-server returns human-readable strings on exceptions. Enhance to also append a json part that can be used in machine invocation contexts to generate exceptions on the remote end. 4. It would be good to send exception information (gracefully handled or otherwise) to collector. 5. Chained exception reporting (not losing information if there is an exception in any complex handling itself) would be good too.
2015-05-08 03:25:08 Nagabhushana R juniperopenstack: importance Undecided Medium
2015-05-08 03:25:15 Nagabhushana R tags config
2015-06-19 01:54:21 Vinay Mahuli nominated for series juniperopenstack/trunk
2015-06-19 01:54:21 Vinay Mahuli bug task added juniperopenstack/trunk
2015-06-19 01:54:21 Vinay Mahuli bug task added juniperopenstack/trunk
2015-06-23 12:03:30 Nagabhushana R information type Proprietary Public
2015-06-26 12:54:18 Vinay Mahuli nominated for series juniperopenstack/r1.1
2015-06-26 12:54:18 Vinay Mahuli bug task added juniperopenstack/r1.1
2015-06-26 12:54:18 Vinay Mahuli bug task added juniperopenstack/r1.1
2015-07-10 22:42:18 Vinay Mahuli nominated for series juniperopenstack/r2.20
2015-07-10 22:42:18 Vinay Mahuli bug task added juniperopenstack/r2.20
2015-07-10 22:42:18 Vinay Mahuli bug task added juniperopenstack/r2.20
2017-05-12 17:50:53 Sachin Bansal juniperopenstack/r1.1: status In Progress Won't Fix
2017-05-12 17:50:58 Sachin Bansal juniperopenstack/r2.20: status In Progress Won't Fix
2017-05-12 17:59:01 Sachin Bansal juniperopenstack/trunk: status In Progress Fix Committed