Count resolution error when providing a bucket_id #41
Comments
|
@AdamTylerLynch 👋 This felt odd to me since the actual ##---------------------------------------------------
## AWS S3 Bucket for storing logs
##---------------------------------------------------
# S3 bucket for storing logs
module "log_storage" {
source = "cloudposse/s3-log-storage/aws"
version = "1.4.2"
name = "account-guardian-logs"
namespace = "ga"
s3_object_ownership = "BucketOwnerPreferred"
bucket_key_enabled = true
versioning_enabled = true
lifecycle_rule_enabled = false
lifecycle_configuration_rules = []
}
##---------------------------------------------------
## AWS Systems Manager Patch Manager
##---------------------------------------------------
module "ssm-patch-manager-critical-al2" {
source = "cloudposse/ssm-patch-manager/aws"
version = "0.6.0"
region = "us-east-1"
approved_patches_compliance_level = "CRITICAL"
namespace = "ga-account-guardian"
operating_system = "AMAZON_LINUX_2"
reboot_option = "NoReboot"
scan_patch_groups = ["al2-automatic"]
install_patch_groups = ["al2-automatic"]
bucket_id = module.log_storage.bucket_id
patch_baseline_approval_rules = [
{
approve_after_days = 0
compliance_level = "HIGH"
enable_non_security = false
patch_baseline_filters = [
{
name = "PRODUCT"
values = ["AmazonLinux2", "AmazonLinux2.0"]
},
{
name = "CLASSIFICATION"
values = ["Security"]
},
{
name = "SEVERITY"
values = ["Critical", "Important"]
}
]
}
]
// Schedule for the maintenance window
// Install, and then scan to see if there are any missing patches/reboots needed
install_maintenance_window_schedule = "cron(0 6 * * ? *)" // Run every day at 6:00 AM
scan_maintenance_window_schedule = "cron(0 7 * * ? *)" // Run every day at 7:00 AM
}
provider "aws" {
region = "us-east-1"
}
terraform {
required_version = ">= 1.0.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = ">= 4.1"
}
}
}Here are my notes from testing in different scenarios:
Net result is that I probably spent 40 minutes on this cause it got me curious, but I did figure it out 😁 In basically doing a git bisect across many different versions, I was able to pin it down to a change in 1.6, which led me to finding this fix / enhancement in the changelog: hashicorp/terraform#33234 Anyway, I'm not sure why someone else hasn't run into this before... but upgrading TF to One thing I found interesting from looking at issues... Mart was saying this was intended back in early 1.0 days: hashicorp/terraform#28962. I'm surprised by that! |
Gowiem
added
good first issue
|
@Gowiem thank you friend! Yes, upgrading the Terraform version to 1.7.4 fixed this issue. |
|
Reopening this issue as I want us on @cloudposse/contributors to get this fixed as others will run into this. I figured the issue out last night, but I didn't write it up all that well. To sum things up, the root cause is that we're using We can get this fixed by adding a We should also do some general cleanup of this module, other PRs, and issues. I will take a stab at this next time I have a clean hour or so. |
* fix!: removes region variable as not used and not needed * chore: cleanup potential issues * fix!: converts bucket_id to list(string) (fix #41) + removes label * chore: bump s3-bucket to latest (4.0.1) * feat: adds approve_until_date support (closes #8) * chore: updates example to show patching (closes #40) * feat: adds s3_bucket_prefix_scan_logs var (closes #14) * chore: readme changes * chore: make tf fmt happy 👍
Describe the Bug
When providing a value for
bucket_id, module can not plan or apply.Expected Behavior
Ability to create my own bucket and provide it as an input
Steps to Reproduce
Screenshots
No response
Environment
terraform --versionTerraform v1.4.2
on darwin_amd64
Additional Context
Plan: 31 to add, 0 to change, 0 to destroy.
╷
│ Error: Invalid count argument
│
│ on .terraform/modules/ssm-patch-manager-critical-al2/ssm_log_bucket.tf line 19, in data "aws_iam_policy_document" "bucket_policy":
│ 19: count = local.create_log_bucket ? 1 : 0
│
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many
│ instances will be created. To work around this, use the -target argument to first apply only the resources that the count
│ depends on.
╵
╷
│ Error: Invalid count argument
│
│ on .terraform/modules/ssm-patch-manager-critical-al2/ssm_log_bucket.tf line 42, in module "ssm_patch_log_s3_bucket":
│ 42: count = local.create_log_bucket ? 1 : 0
│
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many
│ instances will be created. To work around this, use the -target argument to first apply only the resources that the count
│ depends on.
╵
╷
│ Error: Invalid count argument
│
│ on .terraform/modules/ssm-patch-manager-critical-ubuntu20/ssm_log_bucket.tf line 19, in data "aws_iam_policy_document" "bucket_policy":
│ 19: count = local.create_log_bucket ? 1 : 0
│
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many
│ instances will be created. To work around this, use the -target argument to first apply only the resources that the count
│ depends on.
╵
╷
│ Error: Invalid count argument
│
│ on .terraform/modules/ssm-patch-manager-critical-ubuntu20/ssm_log_bucket.tf line 42, in module "ssm_patch_log_s3_bucket":
│ 42: count = local.create_log_bucket ? 1 : 0
│
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many
│ instances will be created. To work around this, use the -target argument to first apply only the resources that the count
│ depends on.
The text was updated successfully, but these errors were encountered: