Removing whitespace in ECR policy forces resource recreation #3839
Comments
|
Hi @suneeta-mall 👋 sorry you're seeing this unexpected behavior. It looks like #3246 which was released in v1.9.0 of the AWS provider has the correct Can you please check that out and let us know if you still have an issue?
The |
bflad
added
question
|
Hey @bflad , Good to know! I am happy to try .. but terraform thinks 1.9.0 is not available and I get this .. Did I miss anything in using 1.9.0? |
|
It looks like you have providers declaring For what its worth, the latest version is 1.11.0. |
|
@bflad Ah silly me! yes you are right .. that was the problem with version issue. Looks like the issue with whitespace outside policy document is not fixed .. even in 1.11.X on version |
|
Hmm. I think at this point I will need to see the actual |
|
@bflad Thanks for pointing in right direction .. It looks like the actual issue is more complicated than we thought .... Looks like if I am on AWS provider # 1.7.X, and I apply more than one policy (3 in this case) on ECR, Terraform thinks its created all the requested policy on ECR (and this is reflected by state file) but actually its only created one of the many policies on ECR resource .. Looking at our outcomes, its not clear which one of the many policies that effectively gets applied. We end up seeing different policy on different ECR but all ECRs have only one policy of 3 we are supplying. Without whitespace change, somehow this behaviour seem to repeatable. I cant not why repeatable apply/plan dont see that ECR is missing 2 policies and only has 1. It just think state file match the state of ECR which is false. Changing whitespace, as mentioned before, outside policy document, on 1.7.x, for some reason causes Terraform to think that policy is changed and now forces the recreation of sources. If I have to guess, I would say, its only actively applying the change thinking the policy is changed and not checking refreshing the true state of ECR?? I am not sure. However, changing the provider version to be 1.11.X, without any changes at all (no whitespace, nothing), causes terraform to think that ECRs needs to be recreated. My guess is because it now finds the difference in state file and actual ECR policy and sees that two are missing and only 1 is present and given that change in ECR is force recreate and it creates the ECR. But I havenot applied them so know what would happen. Heres the trim down and stripped log from my console (for brevity I have removed other ECRs that For the difference of with and without whitespace outside ECR policy on version 1.7.X, the trim down version of logs are:
I am in fix on how to resolve this without having to destroy my ECRs. Since you mentioned, change in ECR policy is force recreate , I have not covered that. I can look at raising a PR later for that when the main issue with ECR is sorted. |
|
When you say "destroy my ECRs", you do not mean your ECR repository (the repository) itself is getting deleted right? The If it does, that seems we should raise an issue with AWS support as that is not a documented behavior: https://docs.aws.amazon.com/sdk-for-go/api/service/ecr/#ECR.DeleteLifecyclePolicy That said, I think you may be confused here because there should only ever be a single resource "aws_ecr_lifecycle_policy" "example" {
# ... other configuration ...
policy = <<EOF
{
"rules": [
{
"rulePriority": 1,
"description": "Keep last 900 images",
"selection": {
"tagStatus": "tagged",
"tagPrefixList": [
"YYY"
],
"countType": "imageCountMoreThan",
"countNumber": 900
},
"action": {
"type": "expire"
}
},
{
"rulePriority": 2,
"description": "Keep last 1 images",
"selection": {
"tagStatus": "tagged",
"tagPrefixList": [
"latest"
],
"countType": "imageCountMoreThan",
"countNumber": 1
},
"action": {
"type": "expire"
}
}
]
}
EOF
}If you need to selectively add or remove the rules depending on some conditional logic, then its doable but requires some extra work with the template data source. |
|
@bflad Ah Indeed I misread the situation and its only ECR policy recreate! That makes perfect sense.. Re aws_ecr_lifecycle_policy, right, I was not aware that its only aws_ecr_lifecycle_policy per ECR . AWS seem to allow to add many... and TF did not complain anyway that we are attaching more than supported. May be I missed the documentation but should this be more obvious? Given I was looking with blind eye for a bit, I will go back and update on the actual whitespace problem again and update you. Thanks for all help! |
|
@bflad I confirm that the issue with policy recreate on whitespace change outside policy is fixed in 1.11.X. I will close this .. Not sure if I care so much about policy reforce recreation if actually the policy has changed. I misinterpreted that as ECR recreate .. that was my bad .. thanks for all the help! |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
ghost
locked and limited conversation to collaborators
breathingdust
removed
the
waiting-response
Terraform Version
0.11.4 (also happens on 0.11.1)
provider "template" (1.0.0)...
provider "aws" (1.7.1)...
Affected Resource(s)
Terraform Configuration Files
Following snippet has whitespace in " "countType": "imageCountMoreThan", " if we remove the trailing whitespace and make it " "countType": "imageCountMoreThan"," terraform thinks its new policy and forces all ecr recreation (see output).
Debug Output
Expected Behavior
Benign changes such as whitespace outside policy values should not cause resource recreation. Actually, unsure why change in policy causes ECR recreation anyway.
Actual Behavior
Should not affect anything .. its whitespace outside the values of policy content. Also, even if the policy content/payload is changed, it should not cause recreation.
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
terraform applywill show that Terraform is going to recreate all ECRsThe text was updated successfully, but these errors were encountered: