Secrets manager takes 30 days to delete a key, which doesn't fit into a terraform workflow if ever a secret needs deleting and recreation.

Use name prefix for aws_secretsmanager_secret instead to prevent the following error:

module.datadog.aws_secretsmanager_secret.datadog_api_key: Creating...
module.datadog.aws_secretsmanager_secret.datadog_api_key: Still creating... [10s elapsed]
module.datadog.aws_secretsmanager_secret.datadog_api_key: Still creating... [20s elapsed]
module.datadog.aws_secretsmanager_secret.datadog_api_key: Still creating... [30s elapsed]
module.datadog.aws_secretsmanager_secret.datadog_api_key: Still creating... [40s elapsed]
module.datadog.aws_secretsmanager_secret.datadog_api_key: Still creating... [50s elapsed]
module.datadog.aws_secretsmanager_secret.datadog_api_key: Still creating... [1m0s elapsed]
module.datadog.aws_secretsmanager_secret.datadog_api_key: Still creating... [1m10s elapsed]
module.datadog.aws_secretsmanager_secret.datadog_api_key: Still creating... [1m20s elapsed]
module.datadog.aws_secretsmanager_secret.datadog_api_key: Still creating... [1m30s elapsed]
module.datadog.aws_secretsmanager_secret.datadog_api_key: Still creating... [1m40s elapsed]
module.datadog.aws_secretsmanager_secret.datadog_api_key: Still creating... [1m50s elapsed]

Error: error creating Secrets Manager Secret: InvalidRequestException: You can't create this secret because a secret with this name is already scheduled for deletion.

  on .terraform/modules/datadog/terraform-aws-datadog-1.0.0/logs_monitoring.tf line 19, in resource "aws_secretsmanager_secret" "datadog_api_key":
  19: resource aws_secretsmanager_secret "datadog_api_key" {

Datadog Lambda Forwarder 3.17.0 with version v1.3.0 is causing following
errors:

1. User:
   arn:aws:sts::XXX:assumed-role/datadog-integration-role/vault-app3.eu1.prod.dog-datadog-delancie-crawler
   is not authorized to perform: states:ListStateMachines on resource:
   arn:aws:states:XXX:XXX:stateMachine:*

2. User:
   arn:aws:sts::XXX:assumed-role/datadog-integration-role/vault-app3.eu1.prod.dog-datadog-delancie-crawler
   is not authorized to perform: elasticfilesystem:DescribeAccessPoints on
   the specified resource

This could be resolved by adding following rows to main.tf:
`@@ -76,6 +76,7 @@ resource "aws_iam_policy" "datadog-core" {
"elasticfilesystem:DescribeAccessPoints",
@@ -115,6 +116,7 @@ resource "aws_iam_policy" "datadog-core" {
"states:ListStateMachines",

Looks like versions.tf requires terraform version to be 0.12. https://github.com/scribd/terraform-aws-datadog/blob/master/versions.tf#L2

The count logic here is relying on resources pre-existing with known outputs:

For example, If comment out the module instantiation, create my s3 bucket, then uncomment the module I can deploy (as the s3 bucket outputs are known beforehand).

If I attempt a DR deployment with the bucket and module instantiation in the same workspace I get the below errors;

Error: Invalid count argument

  on .terraform/modules/datadog/logs_monitoring_cloudtrail.tf line 3, in resource "aws_lambda_permission" "allow-ctbucket-trigger":
   3:   count         = var.cloudtrail_bucket_id != "" ? 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/datadog/logs_monitoring_cloudtrail.tf line 13, in resource "aws_s3_bucket_notification" "ctbucket-notification-dd-log":
  13:   count  = var.cloudtrail_bucket_id != "" ? 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.

Switching to for_each would be the solution but of course lose backwards compatibility.

Added in an August, 2021 change, the extra_policy_arns module variable offers one way to support the optional Datadog / AWS CloudTrail integration.

The implementation's use of for_each may, however, lead to errors of the form:

│ Error: Invalid for_each argument
[...]
│  NNN:   for_each   = toset(var.extra_policy_arns)
│     ├────────────────
│     │ var.extra_policy_arns is list of string with 1 element
│ 
│ The "for_each" 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 for_each depends on.

which I think we should alert users to.

Any plans to go upgrade the module to TF 1.0.0 or 0.15.0?

When deploying the stack I'm running into an issue where the 100 value for ReservedConcurrency defined in the yaml template for the stack is causing a terraform deployment failure as it is failing the minimum value for unreserved concurrency for all functions.

In our case, we have a significant number of lambdas in the same account. In order to successfully forward logs for them, we have to create multiple log forwarder stacks (no problem there). We decided to break them up by microservice for the time being. That leaves us with around 10 log forwarder stacks. Given that the ReservedConcurrency default is 100, those 10 log forwarders quickly burn through the ReservedConcurrency in an account.

I'll submit a PR for an update that would expose a new variable to allow overriding that value while maintaining the 100 default. If this isn't the desired path forward, how have others gotten around this if they have run into it?

terraform-provider-aws 4.0.0 was released, introducing a breaking change to how s3 buckets are defined.

This resource should be refactored to comply with the 4.0 standard. Since doing so breaks compatibility with <4.0.0, this should also increment the major versions and create a new branch.

A migration guide should also be published for users who are on terraform-provider-aws 3.x and desire to upgrade to 4.x

Hey @jim80net, it's pretty uncommon for modules to specify a cap on the required Terraform version, normally they only enforce a minimum. (Any of the aws managed Terraform modules should serve as an example)

Specifying a cap blocks users from upgrading to newer versions and requires that these small PRs are opened and reviewed every time a new version of Terraform is released. Would you guys consider only enforcing a minimum?

Thanks to @dtw45 for the suggestion.

Hi @houqp and @jim80net,

I noticed that the latest merge failed the release pipeline (https://github.com/scribd/terraform-aws-datadog/actions/runs/1698879903). Would it be possible to have this re-run?

Thanks! :)

I want to supply a tags parameter with an arbitrary map of tags, potentially eliminating the hard coded Namespace and Env parameters. So that I don't have to be limited by only env and namespace.

Given we've already an expectation to support these parameters, perhaps in implementation we can simply add tags, and deprecate the namespace and env parameters until users have converged on the new mechanism.

The module's CloudTrail option depends on references to an externally-created S3 bucket. If the bucket already has a notification configuration, the module overwrites it. Conversely, adding a notification configuration outside the module, for some other CloudTrail consumer, overwrites the one created by the module.

A bucket can have only one s3_bucket_notification configuration. Terraform gives no warning at the time a conflicting configuration is introduced. The old configuration is overwritten in AWS, but both the old and new ones end up in Terraform state.

Though there can only be one configuration, it may point to multiple destinations. So, if we went beyond the first step of documenting the side effect, we might be able to accept configuration contents as an optional input, and append. Or, we could eliminate the side effect by removing the s3_bucket_notification resource from the module and leaving it to the user to create or modify their CloudTrail bucket's notification configuration.

Error: Unsuitable value type
On .terraform/modules/datadog/versions.tf line 5: Unsuitable value: string
required

Release 1.3.4 should be skipped. and its changes published to v2.

This breaks when enable_aws_integration is not true.

Actual Behavior

When invoking this module more than once (possibly by defining distinct cloudwatch log groups to forward), the module should generate unique lambda function names to avoid collision of the lambda function resource.

The unique names must be generated from outside the module by supplying unique namespace/env combinations. The namespace and env parameters are used to generate the local stack_prefix.

The documentation isn't clear about this.

If possible, it would be ideal to make this simpler, perhaps by generating the lambda function name some other way.

Expected Behavior

Clear documentation, or, no need to worry about supplying unique namespace/env combinations.

Steps to Reproduce the Problem

1. use the module once to initialize an aws account.
2. use the module again to add cloudwatch log groups, using the same namespace/env combination

Currently, version.tf does not allow using Datadog provider 3.x versions:

  required_providers {
    datadog = {
      source  = "DataDog/datadog"
      version = ">= 2.10, < 3"
    }
  }

This is unfortunate, because it forces everything else in the same deployment to use 2.x version of the provider as well and all the new features come only to 3.x. To me it looks like there is no reason to hold back the version in here, but I might have missed something.

Would it be possible to relax the requirement to allow 3.x versions?