crhelper.py 'timeout' logger is persisted between executions about aws-cloudformation-templates HOT 8 CLOSED

@danieljamesscott I agree,
but whole code of crhelper is 💩, I'm working on and more clean version with hopefully some tests written!

from aws-cloudformation-templates.

I just saw that the finally block with t.cancel() was removed by this PR:

67d4f2a#diff-caf0cd039f3147afdf4f64683b74dad7

Should it be restored?

from aws-cloudformation-templates.

That will help!

I've encountered some other issues to do with logging:

https://forum.serverless.com/t/python-lambda-logging-duplication-workaround/1585

Might be nice to include this fix too.

from aws-cloudformation-templates.

This is my version, it's py3.6+ compatible, but easy to modify for older pythons
https://github.com/1oglop1/aws-cloudformation-templates/blob/master/community/custom_resources/python_custom_resource_helper/crhelper.py

lambda_handler.py

from crhelper import cfn_handler
def create(event, content):
   """Create resource."""
    physical_resource_id = context.log_stream_name
    return physical_resource_id, {"Some": "Data"}
def update(event, context)
    """Update resource."""
    physical_resource_id = event['PhysicalResourceId']
    return physical_resource_id, {}
def delete(event):
    """Delete resource."""
    return event['PhysicalResourceId']
def lambda_handler(event, context):
    cfn_handler(event, context, create, update, delete)

In case you want detailed logging for boto and crhelper, I'd suggest to use common approach to logging config
or simply add these 2 lines in your lambda handler

logging_level=logging.DEBUG
logging.getLogger("botocore").setLevel(logging_level)
logging.getLogger("crhelper").setLevel(logging_level)

You can always write your logic to handle env vars to have it customisable, but that should be your application work, not a library what crhelper should be.

from aws-cloudformation-templates.

@danieljamesscott
I'd like to have your opinion and other who read this:

I was thinking what would be the best Delete behaviour
I came up with 2 options:

1. current state - delete must return physical_resource_id - the value is up on the developer to handle - and must be same as produced by create
   If developer fails to return correct PhysicalResourceId - stack will hang up

def delete(event, context):
    """Delete resource."""
    return event['PhysicalResourceId']

2. delete will not return anything and send_cfn will use event['PhysicalResourceId'] behind the scenes - because it can be either value which came from create or automatic value context.log_stream_name - here the delete should not hang up as the event['PhysicalResourceId'] is always same as it came from create

def delete(event, context):
    """Delete resource."""
    pass 

from aws-cloudformation-templates.

2nd option is probably better? If we can avoid hanging stacks, that would be best.

from aws-cloudformation-templates.

This seems to still be an issue? It's breaking my CustomResource because it will always return a FAILED status, even if it already returned a SUCCESS status resulting in it being stuck in an infinite loop.

from aws-cloudformation-templates.

This implementation has been deprecated in favor of https://github.com/aws-cloudformation/custom-resource-helper which has a richer feature set, is cleaner to implement and can be installed as a pip module.

from aws-cloudformation-templates.