explicit UpdateReplacePolicy

[PatMyron]

fixes aws-cloudformation/cfn-lint#1265

Description of changes: UpdateReplacePolicy currently defaults to Delete anyway, so this change should be a no-op explicitly acknowledging the current default UpdateReplacePolicy value by making it explicit. I'd encourage following up and re-evaluating what UpdateReplacePolicy value really makes sense here, as CloudFormation Linter rules I3011 and W3011 are really just meant to encourage explicit policies because the default values can lead to disastrous surprises

---

63 AssertionErrors to fix 😳

serverless-application-model $ gsed -i -r 's/(DeletionPolicy.*)/\1\n      "UpdateReplacePolicy": "Delete",/' tests/translator/output/**/*.json

[codecov-io]

Codecov Report

Merging #1481 into develop will increase coverage by <.01%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop    #1481      +/-   ##
===========================================
+ Coverage    94.13%   94.13%   +<.01%     
===========================================
  Files           78       78              
  Lines         4925     4927       +2     
  Branches       990      990              
===========================================
+ Hits          4636     4638       +2     
  Misses         134      134              
  Partials       155      155

Impacted Files	Coverage Δ
samtranslator/model/__init__.py	98.14% <100%> (ø)	⬆️
samtranslator/model/sam_resources.py	94.32% <100%> (+0.02%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aba498f...8f5502f. Read the comment docs.

[keetonian]

Clarification questions-

1. Should this be added to every resource that SAM generates?
2. Can you verify that adding this policy does result in a no-op (if I deploy a template, then add this policy and deploy again, CFN does not create/execute a new changeset)?

[PatMyron]

1. Should this be added to every resource that SAM generates?

The main idea behind CloudFormation Linter rule W3011 is that if either one of DeletionPolicy / UpdateReplacePolicy are set to a value to protect resources from deletion, the other policy should at least be explicitly set to something because many don't know about the other policy and someone who has opinions about protecting resources in one situation probably has opinions about protecting resources in the other situation

This PR should at least cover the situations where the AWS::Serverless transform was protecting resources from deletion with DeletionPolicy but not setting any UpdateReplacePolicy which caused noise AWS::Serverless transform customers couldn't fix

---

With that said, there may be other resources where we want to add UpdateReplacePolicy in the future after this PR. Do you have a mapping of AWS::Serverless resource types to all the corresponding CloudFormation resource types they can create?
AWS::Serverless::Application -> AWS::CloudFormation::Stack
AWS::Serverless::SimpleTable -> AWS::DynamoDB::Table
Those are the two mappings I've found so far creating potentially stateful resource types I'll look into more later

[PatMyron]

2. Can you verify that adding this policy does result in a no-op (if I deploy a template, then add this policy and deploy again, CFN does not create/execute a new changeset)?

There is a CloudFormation deployment between these templates (whether change sets are used or not):

Resources:
  Resource:
    Type: AWS::SNS::Topic

Resources:
  Resource:
    Type: AWS::SNS::Topic
    UpdateReplacePolicy: Delete

but there are no stack events concerning the resources themselves, and the default UpdateReplacePolicy was already Delete anyway. Is a no-op CloudFormation deployment an issue?

[keetonian]

A no-op deployment is fine. This looks great, thank you for the contribution.

[ShreyaGangishetty]

This change is updating the hash values of logical ids to some of the Lambda:LayerVersion and Lambda:Version resources which will cause re deployments to the customer templates. We are removing this change from the upcoming release(v1.23.0) and try to schedule this change for next release.

[PatMyron]

This change is updating the hash values of logical ids to some of the Lambda:LayerVersion and Lambda:Version resources which will cause re deployments to the customer templates. We are removing this change from the upcoming release(v1.23.0) and try to schedule this change for next release.

think setting UpdateReplacePolicy after generating the new logical ID should fix this:

diff --git a/samtranslator/model/sam_resources.py b/samtranslator/model/sam_resources.py
index c7665d55a..14c9f540e 100644
--- a/samtranslator/model/sam_resources.py
+++ b/samtranslator/model/sam_resources.py
@@ -1105,12 +1105,13 @@ def _construct_lambda_layer(self, intrinsics_resolver):
         if attributes is None:
             attributes = {}
         attributes["DeletionPolicy"] = retention_policy_value
-        attributes["UpdateReplacePolicy"] = "Delete"
 
         old_logical_id = self.logical_id
         new_logical_id = logical_id_generator.LogicalIdGenerator(old_logical_id, self.to_dict()).gen()
         self.logical_id = new_logical_id
 
+        attributes["UpdateReplacePolicy"] = "Delete"
+
         lambda_layer = LambdaLayerVersion(self.logical_id, depends_on=self.depends_on, attributes=attributes)

but aws-cloudformation/cfn-lint#1529 should mitigate most of the need for this PR anyways