CFn: optional verbose errors

[simonrw]

There is currently lots of exception handling in and around the template deployer within CloudFormation. This makes it more complex to understand what goes wrong with stack deployments.

This change adds a config variable to present exceptions either:

• fully, raising the exception up, or
• logging at exception level the message, exception and traceback, instead of logging at a lower level (often debug) with a possibly less-than-helpful error message.

This feature can be enabled with the CFN_VERBOSE_ERRORS configuration variable/environment variable.

[coveralls]

Coverage: 82.239% (-0.01%) from 82.254% when pulling 4e7a08e on cfn/verbose-errors into 8f43432 on master.

[github-actions]

LocalStack Community integration with Pro

2 045 tests   1 761 ✔️  1h 16m 30s ⏱️
       2 suites     284 💤
       2 files           0 ❌

Results for commit 4e7a08e.

[thrau]

Thanks @simonrw! It's great to see instrumentation improving in LocalStack and giving us more dials to turn when debugging.

I'm trying to understand whether this flag is targeted at users to allow them to look into why their stack isn't deploying, or whether this is targeted as a debugging tool for LocalStack (much like DEBUG=1. In which case my follow up question would be whether this is generalizable under a DEBUG_CFN flag that enables a debug mode for cloudformation (we have this pattern in other areas as well, DEBUG_HANDLER_CHAIN, DEBUG_ANALYTICS, DEBUG_LICENSING, etc).

If there is a particular reason to toggle only exception reporting, it seems we may consider doing things differently all together and raise exceptions rather than catching and logging them?

[simonrw]

I'm trying to understand whether this flag is targeted at users to allow them to look into why their stack isn't deploying, or whether this is targeted as a debugging tool for LocalStack (much like DEBUG=1.

I would see this as mostly helpful for us - if a user receives a verbose error or exception, they are not immediately going to know how to resolve their problem, or even if it's a problem on their end.

In which case my follow up question would be whether this is generalizable under a DEBUG_CFN flag that enables a debug mode for cloudformation (we have this pattern in other areas as well, DEBUG_HANDLER_CHAIN, DEBUG_ANALYTICS, DEBUG_LICENSING, etc).

I'm happy to include this plus potentially more introspection tools under a common flag.

If there is a particular reason to toggle only exception reporting, it seems we may consider doing things differently all together and raise exceptions rather than catching and logging them?

Only that it is the minimal set of changes. We will likely revisit this concept when we get further into our refactoring. In addition, the current implementation is very trial and error, and it doesn't make sense to raise every exception since some are sort of expected (not ideal IMO).

[thrau]

merging this for now, since i actually needed it the other day :P