aws_lambda_function undefining values

[pimperator]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform AWS Provider Version

Terraform v1.1.0
on darwin_amd64
+ provider registry.terraform.io/hashicorp/archive v2.2.0
+ provider registry.terraform.io/hashicorp/aws v4.1.0

Affected Resource(s)

• aws_lambda_function

Terraform Configuration Files

I have some glue-code here but please note: we want either to create lambdas with either a zip-file from s3 or like here with a container.

So the glue code raises the error but note that aws_lambda_function and aws_ecr_repository are comeing from different modules handing over needed values via outputs.

locals {
  module_tags = {
    Module = "lambda"
  }
  tags = merge(var.tags, local.module_tags,
    tomap({ "Name" = "some-name" })
  )
  s3_bucket = "static-bucket-name"
  s3_key = "path/to/function.zip"
  image_uri = aws_ecr_repository.repo.repository_url == null ? null : join(":",[aws_ecr_repository.repo.repository_url,"latest"])
}

resource "aws_iam_role" "iam_for_lambda" {
  name = "${local.tags.Name}-lambda"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

resource "aws_ecr_repository" "repo" {
  name = local.tags.Name

  image_tag_mutability = "MUTABLE"

  image_scanning_configuration {
    scan_on_push = false
  }
}

resource "aws_lambda_function" "this" {
  function_name = local.tags.Name
  role          = aws_iam_role.iam_for_lambda.arn


  s3_bucket = local.image_uri == null ? null : local.s3_bucket #<<<<<<<<<<<<<<
  s3_key    = local.image_uri == null ? null : local.s3_key #<<<<<<<<<<<<<<

  memory_size = 128

  runtime = "python3.9"
  handler = "lambda_function.lambda_handler"

  architectures = ["x86_64"]

  timeout   = 5
  publish   = false
  image_uri = local.image_uri #<<<<<<<<<<<<<<


  tags = local.tags
}


variable "image_uri" {
  type        = string
  default     = null
  description = "uri to ecr image"
}

variable "tags" {
  type = map(any)
}

Debug Output

│ Error: Conflicting configuration arguments
│
│   with module.container.module.lambda.aws_lambda_function.this,
│   on .terraform/modules/container.lambda/main.tf line 43, in resource "aws_lambda_function" "this":
│   43:   s3_bucket = local.s3_bucket
│
│ "s3_bucket": conflicts with image_uri
╵
╷
│ Error: Conflicting configuration arguments
│
│   with module.container.module.lambda.aws_lambda_function.this,
│   on .terraform/modules/container.lambda/main.tf line 44, in resource "aws_lambda_function" "this":
│   44:   s3_key    = local.s3_key
│
│ "s3_key": conflicts with image_uri
╵
╷
│ Error: Conflicting configuration arguments
│
│   with module.container.module.lambda.aws_lambda_function.this,
│   on .terraform/modules/container.lambda/main.tf line 57, in resource "aws_lambda_function" "this":
│   57:   image_uri = var.image_uri
│
│ "image_uri": conflicts with s3_bucket

Panic Output

Expected Behavior

The expected behaviour here is that the following combinations are allowed:

1. first configuration possibility with image_uri

resource "aws_lambda_function" "this" {
#...
  s3_bucket              = null
  s3_key                    = null
  s3_object_version = null
  filename                  = null
  image_uri               = local.image_uri #<<<<<<<<<<<<<< 
#...
}

1. second configuration possibility with s3 object

resource "aws_lambda_function" "this" {
#...
  s3_bucket              = bucketname                         #<<<<<<<<<<<<<< 
  s3_key                    = path/to/key.zip                     #<<<<<<<<<<<<<< 
  s3_object_version = ${object-version-optional} #<<<<<<<<<<<<<< 
  filename                  = null
  image_uri               = null
#...
}

1. third configuration possibility with filename

resource "aws_lambda_function" "this" {
#...
  s3_bucket              = null
  s3_key                    = null
  s3_object_version = null
  filename                  = "${path.module}/function/function.zip"       #<<<<<<<<<<<<<< 
  image_uri               = null
#...
}

Actual Behavior

For now you cannot define the 5 values at once. Only the combinations {s3_bucket, s3_key, s3_object_version}, {filename} or {image_uri} is allowed but for having one generic lambda module it would be awesome to being able to make the values undefined.

Steps to Reproduce

1. terraform apply

Important Factoids

References

• resource/lambda_function: Enhance plan-time validation #16515
• add image_uri to data source aws_lambda_function #21015

[gbataille]

Hi @pimperator

I was trying to have a look into this.
I found some evaluation deferral in such a case where a variable in computed: https://github.com/hashicorp/terraform-plugin-sdk/blob/6de4ff033a23058dd0a383df46212c304ff16756/helper/schema/schema.go#L1675

Then I tried to reproduce it with
terraform 1.1.6 and aws provider 4.2.0
and I can't. It seems to work as expected.

What I could see however is that I can trigger this "conflict" error if I set local.image_uri to a non-null value. So it feels to me that this issue has been fixed (and released) recently.

Could you please upgrade and retry?

[pimperator]

Dear @gbataille ,

yes, it still persists on my testing-code (not the glue-code from above):

terraform version
Terraform v1.1.6
on darwin_amd64
+ provider registry.terraform.io/hashicorp/archive v2.2.0
+ provider registry.terraform.io/hashicorp/aws v4.2.0

╷
│ Error: Conflicting configuration arguments
│
│   with module.container.module.lambda.aws_lambda_function.this,
│   on .terraform/modules/container.lambda/main.tf line 43, in resource "aws_lambda_function" "this":
│   43:   s3_bucket = var.image_uri == null ? null : local.s3_bucket
│
│ "s3_bucket": conflicts with image_uri
╵
╷
│ Error: Conflicting configuration arguments
│
│   with module.container.module.lambda.aws_lambda_function.this,
│   on .terraform/modules/container.lambda/main.tf line 44, in resource "aws_lambda_function" "this":
│   44:   s3_key    = var.image_uri == null ? null : local.s3_key
│
│ "s3_key": conflicts with image_uri
╵
╷
│ Error: Conflicting configuration arguments
│
│   with module.container.module.lambda.aws_lambda_function.this,
│   on .terraform/modules/container.lambda/main.tf line 57, in resource "aws_lambda_function" "this":
│   57:   image_uri = var.image_uri
│
│ "image_uri": conflicts with s3_bucket

let me check how I can better re-trigger this issue and put some better code (locally applied) for your tests.

Cheers

Erik

[pimperator]

Dear @gbataille
you were right. there is no bug or issue here.
The problem was behind the keyboard.

I had to switch the conditionals for s3_bucket and s3_key to make it work. Also I had bo provide a package_type depending on either image_uri or function zip:

resource "aws_lambda_function" "this" {
  function_name = local.tags.Name
  role          = aws_iam_role.iam_for_lambda.arn


  s3_bucket = local.image_uri == null ? local.s3_bucket : null  #<<<<<<<<<<<<<<
  s3_key    = local.image_uri == null ? local.s3_key : null  #<<<<<<<<<<<<<<

  memory_size = 128

  runtime = "python3.9"
  handler = "lambda_function.lambda_handler"

  architectures = ["x86_64"]

  timeout   = 5
  publish   = false
  image_uri = local.image_uri #<<<<<<<<<<<<<<
  package_type = local.image_uri == null ? "Zip" : "Image"

  tags = local.tags
}

The only thing that I now need to look into is how to provide an image_uri on creation for a non-existing container-tag since this makes terraform fail.

Nevertheless we can see the issue solved.

Thanks a lot for your help and best wishes form Bavaria!

Erik

[github-actions]

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.