You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're facing a quite weird issue when trying to re-run a non-changing Lambda function that lives within a VPC (security group and subnet IDs configured as inputs). Our configuration is quite simple and sticks with your complete example inside this module. I noticed there was a very similar issue raised by another chap and fixed here, but this seems different as only occurs when the Lambda gets deployed into a VPC
No significant changes nor nothing that would lead to a confusion, latest version of terraform-aws-lambda consumed as a module.
We think this issue may reside in the null_resource.deploy because the Lambda function itself "changed" based on the data resource it gather at runtime. If we for instance, change the publish variable to false in a subsequent execution, the module remains idempotent as such.
Based on more recent updates, an issue with the AWS provider forces a change to happen. These resources may be affected:
aws_lambda_function
aws_iam_role 👈 I have observed a similar problem with aws_iam_role in 3.12.0 as well.
Using vanilla Terraform 0.14.6 at the minute. An snippet of a subsequent terraform apply execution that produces this error.
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
-/+ destroy and then create replacement
<= read (data resources)
Terraform will perform the following actions:# module.lambda_deploy.data.aws_iam_policy_document.assume_role[0] will be read during apply# (config refers to values not yet known)<=data"aws_iam_policy_document""assume_role" {
~ id="12345678"-> (known after apply)
~ json=jsonencode(
{
- Statement = [
- {
- Action ="sts:AssumeRole"- Effect ="Allow"- Principal = {
- Service ="codedeploy.amazonaws.com"
}
- Sid =""
},
]
- Version ="2012-10-17"
}
) -> (known after apply)
-version="2012-10-17"->null
~ statement {
-not_actions=[] ->null-not_resources=[] ->null-resources=[] ->null# (2 unchanged attributes hidden)# (1 unchanged block hidden)
}
}
# module.lambda_deploy.data.aws_lambda_alias.this[0] will be read during apply# (config refers to values not yet known)<=data"aws_lambda_alias""this" {
~ arn="(SENSITIVE)"-> (known after apply)
+description=(known after apply)
~ function_version="1"-> (known after apply)
~ id="(SENSITIVE)"-> (known after apply)
~ invoke_arn="(SENSITIVE)"-> (known after apply)
name="dev"# (1 unchanged attribute hidden)
}
# module.data.aws_lambda_function.this[0] will be read during apply# (config refers to values not yet known)<=data"aws_lambda_function""this" {
~ arn="(SENSITIVE)"-> (known after apply)
+code_signing_config_arn=(known after apply)
~ dead_letter_config=[] -> (known after apply)
~ description="(SENSITIVE)"-> (known after apply)
~ environment=[
- {
- variables = {
-"(SENSITIVE)" = "(SENSITIVE)"
}
},
] -> (known after apply)
~ file_system_config=[] -> (known after apply)
~ handler="index.handler"-> (known after apply)
~ id="(SENSITIVE)"-> (known after apply)
~ invoke_arn="(SENSITIVE)"-> (known after apply)
+kms_key_arn=(known after apply)
~ last_modified="2021-02-10T12:17:18.647+0000"-> (known after apply)
~ layers=[] -> (known after apply)
~ memory_size=256-> (known after apply)
~ qualified_arn="(SENSITIVE):1"-> (known after apply)
~ qualifier="1"-> (known after apply)
~ reserved_concurrent_executions=-1-> (known after apply)
~ role="(SENSITIVE)"-> (known after apply)
~ runtime="nodejs12.x"-> (known after apply)
+signing_job_arn=(known after apply)
+signing_profile_version_arn=(known after apply)
~ source_code_hash="FhBljq72lzd6yS3/="-> (known after apply)
~ source_code_size=(SENSITIVE)-> (known after apply)
~ tags={} -> (known after apply)
~ timeout=10-> (known after apply)
~ tracing_config=[
- {
- mode ="PassThrough"
},
] -> (known after apply)
~ version="1"-> (known after apply)
~ vpc_config=[
- {
- security_group_ids = [
-"(SENSITIVE)",
]
- subnet_ids = [
-"subnet-(SENSITIVE)",
-"subnet-0(SENSITIVE)",
-"subnet-0(SENSITIVE)",
]
- vpc_id ="vpc-0(SENSITIVE)"
},
] -> (known after apply)
# (1 unchanged attribute hidden)
}
# module.lambda_deploy.aws_iam_role.codedeploy[0] will be updated in-place
~ resource"aws_iam_role""codedeploy" {
~ assume_role_policy=jsonencode(
{
- Statement = [
- {
- Action ="sts:AssumeRole"- Effect ="Allow"- Principal = {
- Service ="codedeploy.amazonaws.com"
}
- Sid =""
},
]
- Version ="2012-10-17"
}
) -> (known after apply)
id="(SENSITIVE)"name="(SENSITIVE)"tags={}
# (6 unchanged attributes hidden)
}
# module.lambda_deploy.null_resource.deploy[0] must be replaced-/+resource"null_resource""deploy" {
~ id="(SENSITIVE)"-> (known after apply)
~ triggers={
-"appspec_sha256" = "4e64a69ea61baad2bc"-"force_deploy" = "false"
} -> (known after apply) # forces replacement
}
# module.lambda_function.aws_lambda_function.this[0] will be updated in-place
~ resource"aws_lambda_function""this" {
id="(SENSITIVE)"
~ qualified_arn="(SENSITIVE):1"-> (known after apply)
tags={}
~ version="1"-> (known after apply)
# (18 unchanged attributes hidden)# (3 unchanged blocks hidden)
}
Plan:1 to add, 2 to change, 1 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value:
Any help would be appreciated!
The text was updated successfully, but these errors were encountered:
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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Hey folks,
EDIT1: Looks like a wider AWS Terraform provider bug/issue --> hashicorp/terraform-provider-aws#17385
EDIT2: Some work kicked off on a PR that initially patches this issue. More info hashicorp/terraform-provider-aws#17610 - Remember to vote with a 👍🏼
We're facing a quite weird issue when trying to re-run a non-changing Lambda function that lives within a VPC (security group and subnet IDs configured as inputs). Our configuration is quite simple and sticks with your complete example inside this module. I noticed there was a very similar issue raised by another chap and fixed here, but this seems different as only occurs when the Lambda gets deployed into a VPC
No significant changes nor nothing that would lead to a confusion, latest version of
terraform-aws-lambda
consumed as a module.We think this issue may reside in thenull_resource.deploy
because the Lambda function itself "changed" based on the data resource it gather at runtime. If we for instance, change thepublish
variable to false in a subsequent execution, the module remains idempotent as such.Based on more recent updates, an issue with the AWS provider forces a change to happen. These resources may be affected:
Using vanilla Terraform 0.14.6 at the minute. An snippet of a subsequent
terraform apply
execution that produces this error.Any help would be appreciated!
The text was updated successfully, but these errors were encountered: