-
|
I have a CustomResource that uses a the lambda arn as the service token instead of a provider service token to create Thing Groups in IoT. This has caused issues where when the thing group fails to create, CDK/Cloudformation hangs. I have tried changing it from the Lambda ARN to a Provider service token as the CustomResource service token yet I get this error: How can I safely migrate to a Provider serivce token from a Lambda Arn as the Custom Resource Service Token without deleting the Thing Group and recreating it again? Or do I literally have to delete the Thing Group and Re-Create it because I have no choice but to do so due to the constraints of Cloudformation and CDK? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
Hello! Reopening this discussion to make it searchable. |
Beta Was this translation helpful? Give feedback.
-
|
As long as it is acceptable to destroy/create the custom resource, you can modify the logical ID by finding the CfnResource for the custom resource and calling overrideLogicalId. Usually this is acceptable unless the LogicalId is part of the resource lambda logic. A single deployment with the new logical ID is all that is required. Since it is a new Logical ID, CloudFormation will not see it as a service token change. After that, you can go back to the original logical ID if you like. See my code here that does this. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, we just updated the handler to not destroy the resources but only in Cloud-formation it is "deleted". In the second phase we have it where it 're-creates" it but we deal with the error that it was "re-created" in the Custom Resource handler. Had I known this, I might have done it this way. Thanks for your answer. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! Reopening this discussion to make it searchable. |
Beta Was this translation helpful? Give feedback.
As long as it is acceptable to destroy/create the custom resource, you can modify the logical ID by finding the CfnResource for the custom resource and calling overrideLogicalId. Usually this is acceptable unless the LogicalId is part of the resource lambda logic.
A single deployment with the new logical ID is all that is required. Since it is a new Logical ID, CloudFormation will not see it as a service token change. After that, you can go back to the original logical ID if you like.
See my code here that does this.