#terraform (2022-03)

We have had this problem too

Usually something wrong with the webhooks for the repo. We end up having to manually trigger a refresh

@matt has tried to ask HashiCorp for support, but I believe no response

yeh that is super frustrating

i have re-synced the registry is update and now atlantis reckons it can’t find the version of the module

it seems we get a {"errors":["payload signature check failed"]} on the repos webhook

We are talking about it

i once read that if something is used for critical/production use cases, then it is 1.0 regardless of whether anyone thinks it is ready for that, and it should be versioned accordingly. that got me over all my hesitance. but i also make no promises about long-term support for any given version. if a change is backwards incompatible, no matter how minor, that gets a major version bump.

yes I know some people don’t like big major version numbers for aesthetic reasons, they want to get the design right and release v1 which never increments. But Terraform/AWS provider make that impossible

so right now, I believe we need to do it, it’s more about how to do it “at scale”. I hate that expression, but it really makes sense. Most companies doing releases have less than a handful to worry about. We have hundreds, more than any release manager can keep track of - but let’s discuss.

Looking at major projects, e.g. kubernetes, they create a branch release-x.y for every release, so that patches can be made. Istio, et al follow this exact convention.

Then look at Terraform and all their providers. They don’t do this! This seems like huge mental overhead, but nonetheless intrigued why they don’t.

i believe terraform does it also… e.g. https://github.com/hashicorp/terraform/tree/v1.1

which makes sense if you intend to patch older versions. though i guess you don’t have to persist the branch… you can always recreate it from a tag

Yeah. I don’t think you need to change the support timeline after bumping to 1.0. Everything about CloudPosse modules is really great at the moment, all I care about is the lack of semantic version numbers

I see the current auto-release logic relies on adding a label to each PR to define if it’s a major, minor, or patch release

You mentioned recently you don’t like chatops. One approach would be to change the merge process from “click the green merge button” to “apply the ‘merge’ label and one of ‘major/minor/patch’ labels, and github actions will process the PR merge”

I’m happy to prototype this in a new repo if you’d like to try it

mergify can implement that workflow also, e.g. “merge if label exists and required jobs pass”

You mentioned recently you don’t like chatops. One approach would be to change the merge process from “click the green merge button” to “apply the ‘merge’ label and one of ‘major/minor/patch’ labels, and github actions will process the PR merge” That’s an interesting idea.

cc @Dylan @Jeremy G (Cloud Posse)

I don’t see the advantage there. Currently the release defaults to a minor version increment unless otherwise labeled. I do not like giving Mergify the permission to do the merges because it increases the risk of malware or inadvertent breaking changes being released.

(We already have this problem when a dependent module has a breaking change and Renovate updates the module to use the new version and Mergify auto-approves and merges it. This problem will be resolved when all our modules go past major version zero, as we will prohibit automatic updates of major version updates, but for the near future this will remain a problem.)

@Erik Osterman (Cloud Posse) I think if we can get comfortable with eventually having version 126.0.0 we can switch to full SemVer with the next breaking release and otherwise not bother with ongoing support of earlier versions. In practice we rarely make breaking changes, so the major versions should not increment that fast, and we rarely update old versions, instead forcing people to accept the breaking change if they want new features. It’s not the best customer experience, but it is at the limit of what Cloud Posse can do for free, so all that would really change is that we would be making our level of support more explicit.

If we found we wanted/had to update an old version, say to patch a security issue, we could create a branch at that time. I expect that will be a rare occurrence, at least until Terraform v2 comes out.

[main.tf](http://main.tf):

module "yaml_config" {
  source = "cloudposse/config/yaml"
  map_config_local_base_path = "./config"

  map_config_paths = [
    "regsync.yaml"
  ]

  context = module.this.context
}

./config/regsync.yaml:

sync:
  - source: consul
    target: docker.local/mirror/consul
    type: repository
    tags:
      allow:
        - "latest"
        - "1\\.9.*"

  - source: cr.l5d.io/linkerd/grafana
    target: docker.local/mirror/linkerd/grafana
    type: repository
    tags:
      allow:
        - "stable-2\\.10\\..*"

  - source: tricksterproxy/trickster
    target: docker.local/mirror/tricksterproxy/trickster
    type: repository

That last entry in the sync list, which doesn’t have a tag key, fails the deep merge..

│ Error: Invalid function argument
│ 
│   on .terraform/modules/yaml_config/modules/deepmerge/depth.tf line 43, in locals:
│   43:           for key in keys(item["value"]) :
│     ├────────────────
│     │ item["value"] is tuple with 12 elements
│ 
│ Invalid value for "inputMap" parameter: must have map or object type.
╵
╷
│ Error: Invalid function argument
│ 
│   on .terraform/modules/yaml_config/modules/deepmerge/depth.tf line 55, in locals:
│   55:           for key in keys(item["value"]) :
│     ├────────────────
│     │ item["value"] is tuple with 12 elements
│ 
│ Invalid value for "inputMap" parameter: must have map or object type.
╵
Releasing state lock. This may take a few moments...

If I add a tag: {} on that last one it is fine.

I should maybe just file + yamldecode as I don’t really utilize the config module properly anyway…

all entries must have the same type and number of elements

this is how the TF code what we are using for deep-merge works

Yeah… Thanks. I just wanted to start using the yaml-config module so I used it even though I didn’t actually need it right here . Converted to a yamldecode(file()) now .

if you are just reading YAML files and converting to TF structures, you don’t need the module

it’s only for deep-merge of maps which TF merge does not support

(and for remotely reading YAML)

With our terraform framework we use it compulsively because it’s so easy. Just as easy as reading from SSM. So if you expect to be integrating with things outside of terraform, build a remote state framework around SSM and if just working with terraform, then remote state is fine.

I think you will hear some counter arguments, but what are the alternatives? You can do a terralith and just access all settings directly. Terraliths are anti patterns. You can copy pasta all the settings. That’s not DRY and very error prone. You can use data sources, but not everything can be looked up that way.

got an example module?

nevermind, I learned a new skill today: search!

ok, yeah, based on this and this I’d say I’m about to implement basically what you’re doing

actually, is this repo currently used? almost a year without any commits, seems unlike you.

It is indeed, but we are behind upstreaming components

You’ll see many of the components are more recently updated and many open PRs

Here’s an example: https://github.com/cloudposse/terraform-aws-components/blob/master/modules/alb-controller/remote-state.tf

However, beadvised, our remote-state implementation is based on our stack configurations, so if you’re not using our stack configurations, the remote state lookups won’t work.

I would prefer data sources its like query your aws resources to get their ids

and I don’t need to worry about outputs from other state files or how stacks or single stack being used

and if you need extra non-normal use case you can stick with SSM

it makes sense to add a new input variable to support importing existing databases into the rds module

before submitting the pr, please check if you can fully import the database and set the appropriate inputs so the module returns “no changes”

Here is the PR (not sure who to ping about it) https://github.com/cloudposse/terraform-aws-rds-cluster/pull/133

Thank you @Tyler Jarjoura for the contribution.

This has been released as https://github.com/cloudposse/terraform-aws-rds-cluster/releases/tag/0.50.2

aha, instead of putting a for_each in the aws_iam_role_policy to attach the multiple policies, just did another aws_iam_policy_document with source_policy_documents set to the list

then passed that to aws_iam_role_policy

I just deployed this 5 mins ago and all good here. Terraform’s aws provider version 4 breaks everything that uses s3 though. I set it up with aws version 3, I think you’d have to do that, only modules that support v4 specifically would work, unless you can use multiple versions of a provider.

aws = {
      source = "hashicorp/aws"
      version = "~> 3.0"
    }

okay let me see which aws version it has

thanks @Michael Galey that seems to have been it… I hadn’t version locked hashicorp/aws and it grabbed v4

yea same, that’s been the source of errors across my 40 state files for the last week , glad it worked out!

I suspect we’ll have a v4 version soon

Yeah I’ve got a bunch of my own terraform IaC that needs to be looked at for v4 compatibility ad well

same issue as the above message talking about s3 depending on the aws provider version?

interesting.. ty!

I believe the eks cluster uses it’s own kubernetes provider so you may have conflicting providers here between your consumer module and the consumed module

https://github.com/cloudposse/terraform-aws-eks-cluster/blob/b745ed18d8832c7e8e53966264687d2ee1d64e1a/auth.tf#L88

see the example here which doesnt use the kubernetes provider in the consumer/root module https://github.com/cloudposse/terraform-aws-eks-cluster/blob/master/examples/complete/main.tf and relies on the eks cluster module’s kubernetes provider

cc: @Jeremy G (Cloud Posse)

removed the provider as you suggested but still it does not work…

null_resource.add_custom_tags_to_asg: Refreshing state... 
╷
│ Error: Get "<http://localhost/api/v1/namespaces/kube-system/configmaps/aws-auth>": dial tcp [::1]:80: connect: connection refused
│
│   with module.eks_cluster.kubernetes_config_map.aws_auth_ignore_changes[0],
│   on .terraform/modules/eks_cluster/auth.tf line 115, in resource "kubernetes_config_map" "aws_auth_ignore_changes":
│  115: resource "kubernetes_config_map" "aws_auth_ignore_changes" {
│
╵

@David Are you using kube_exec_auth_enabled ? As explained in the release notes for eks-cluster v0.42.0, authentication is an ongoing problem, for which “exec auth” is our preferred workaround.

maybe @David you could be tripping over this issue https://github.com/cloudposse/terraform-aws-eks-cluster/issues/143

see the workarounds

Hey @Ross Rochford super late but I was involved in something similar a few years ago. We used SaltStack with SNS and cloudwatch events (now called EventBridge I believe).

Salt has a REST API and can do everything on your list above.

I have not done anything with salt since then and I don’t know the state of the FOSS project, especially since VMware bought them.

If it works on the second apply then I would assume that your trust policy is referencing a role (or something similar) that it is not dependent on. Therefore it is trying to create the policy prior to the referenced resource being created and then :boom: .

You can try to find that dependent resource and explicitly define the relationship using depends_on OR you can reference the dependent resource directly in the policy and it will create that relationship for you (the preferred approach).

This is a guess from a small amount of information, but that is a common problem.

https://www.terraform.io/cloud-docs/api-docs/ssh-keys

thank you for your response, i have been able to take cli control with the terraform login command, but seems it can’t understand the state already used in terraform cloud and it wants to recreate everything. do i understand well that terraform import is not possible when using terraform cloud? found also many other enterprise users struggling with it, and the clear answer from tf employees is “sorry it works as it should” here

@Almondovar Are you making sure to select the correct workspace ( e.g. terraform workspace select) that Terraform Cloud is using? I could imagine that being your issue.

Thank you Matt, i am not sure these are applicable on the terraform cloud, because although i am connected with the token correctly

Terraform must now open a web browser to the tokens page for app.terraform.io.

If a browser does not open this automatically, open the following URL to proceed:
    <https://app.terraform.io/app/settings/tokens?source=terraform-login>

i cant see my workspaces

> terraform workspace list      
* default

That’s how we do it - packer builds a base image with all of the prereqs, then user data runs PowerShell to configure IIS.

Could also use DSC or similar, which would be a little cleaner, but I haven’t gone down that road.

@Jim G

The way its going for me so far is:

1. Running Install-WindowsFeature to install all the IIS modules
2. Calling New-WebApplication to set up a site How do you handle the IIS config? Like setting headers, and HTTPS redirects?

Sorry, to clarify:

• We use packer to install IIS and any other prereqs or configuration that can be done in the image.

• user_data is just used to bootstrap the image (configure Splunk, Cloudwatch Agent) and install our deployment system agent to phone home (in our case, Octopus Deploy)

• The deployment system actually deploys the website content and configures IIS.

I wouldn’t want to do all of that in user_data - it would be slow and hard to debug.

Ah,that’s a good point; I’ve noticed an error during the user_data call can mess with the SSM agent - other stuff too probably

I don’t know much about packer other than that it deals with os images, whats the major advantage vs creating a custom AMI w/ AWS?

speed. You can do all of the installs, config, whatever once when baking the AMI. Then during terraform apply, it’s already in the image - you’re not waiting for 10,000 lines of user_data to execute.

and with Windows instances, that adds up pretty quickly

it also helps if you’re trying to build immutable infrastruture - we don’t patch our windows instances. Once a month, we build a new (patched) AMI with packer, then do a rolling replacement of all of our instances.

that’s pretty cool!

Can you point me to any resources for creating an IIS image w/ packer?

If there’s any information i’ve omitted that might help understand where i sit please let me know

any ideas?

I tried TF 0.14, 1.1.7, deleting .terraform and nothing, same problem

delete the lock file in the same folder

.terraform.lock.hcl

I do not have a lock file

can the awscc and aws provider coexist? I will imagine that it should

did you try terraform providers?

also, do you use a .terraformrc file, or set the env TF_PLUGIN_CACHE_DIR?

try to delete .terraform.d folder in HOME dir

I have no .terraform* any files

I can run terraform providers

you should have the folder in ~/.terraform.d

let me check that one

in your HOME

not in the repo

yes, I just deleted it

does awscc work with 13.7?

I wonder if it has to be 1.x

could be that the state is 0.13.7 and is an older version so it needs to be updated?

after deleting the folder, did you run terraform init again?

yes

otherwise you can’t plan, the problem happens on plan only

so I cleaned up the code

my main.tf is empty

new dir

just the one provider

same thing :

 terraform plan

Error: Could not load plugin


Plugin reinitialization required. Please run "terraform init".

Plugins are external binaries that Terraform uses to access and manipulate
resources. The configuration provided requires plugins which can't be located,
don't satisfy the version constraints, or are otherwise incompatible.

Terraform automatically discovers provider requirements from your
configuration, including providers used in child modules. To see the
requirements and constraints, run "terraform providers".

Failed to instantiate provider "registry.terraform.io/hashicorp/awscc" to
obtain schema: Incompatible API version with plugin. Plugin version: 6, Client
versions: [5]

ok so

I did the same, but with tf 1.1.7 and it works

I think the minimum version required is 0.15

yep

0.15.0 is the minimum required version

where is that in the docs?

i was looking for a min tf version for the awscc provider but didn’t see one. i do think that 0.15.0 is the last time they made changes to the state schema though, so kinda makes sense

https://github.com/hashicorp/terraform-provider-awscc/issues/429

please vote

Note I don’t have this problem when using a network load balancer. I’m looking for recommendations to reduce the noise in my plan output.

it’s difficult to give recommendation. What we saw with elastic beanstalk, the API returns the data in different order, and TF can’t compare it correctly. This issue going on for years

In this case it seems like the module is specifying a bunch of parameters that aren’t used, so the platform returns nulls. Then the plan tries to update them again to what is specified.

yes, that’s the case

So, is this a bug in the module? And if so, should I file it? I mean, it doesn’t solve my immediate problem, but it seems like it should be fixed.

it’s not easy to fix (there are many combinations of settings). Unless we don’t add any settings to the module and let the caller to provide whatever they want

for this reason we don’t use the CloudPosse module. Instead, we create the environments directly and pass in the exact settings we need. Elastic Beanstalk’s resources in Terraform are not great. EB is very opinionated, and its opinions don’t work well with Terraform. It needs to be handled with care and close attention, for better or worse

we prob need to make all the settings optional and provide a variable to override all of them

It seems as though this is the local I need to change - unsure if I can do so from my workspace.

Sorry for the late reply but if you don’t want to use s3 i think this module might be a better fit for your use case https://github.com/cloudposse/terraform-aws-cloudfront-cdn

Thanks @jedineeper for the reply. I am using S3 as one origin, however not as the default. Are you aware of a way to utilise the module in this way?

I think that the module i linked allows you to define your own origin structure, be it s3 or something else

pretty sure the s3-cdn module uses it as a base so you could probably look into THAT module to see how the origins are defined as I’m not 100% sure

Unfortunately, we have no guidance/recommendations for this. Refactoring is a very small part of what we do. Possibly because we create very small components already built on our terraform modules, which are also pretty small and single purpose.

Where we still get bit is when the provider interface changes (e.g. S3 buckets) and for that, Terraform provides little to make it less painful.

We are grappling with one area of refactoring that’s very painful: how we handle security groups.

I can’t recall if @ looked into using moved to help with that

As for moved we are dealing with a cross-package move by making a module local to the root module first. And the second step is to make it external.

That makes sense. Tedious but probably no better way

could you create a ticket on the repo? this will help us to track it

if you’re feeling ambitious, you could even submit a pr for the addition

Thanks for answering!! i can create a ticket yes

cc @matt

Hi , There was a fully fledged Terraform landing zone (https://www.hashicorp.com/resources/aws-terraform-landing-zone-tlz-accelerator) , though this has been replaced with Terraform integration with AWS Control Tower https://aws.amazon.com/blogs/aws/new-aws-control-tower-account-factory-for-terraform/.

Thanks! Is my understanding correct, that I need a TF cloud account for TLZ?

TF Cloud or Enterprise would be best in my experience, using S3/Dynamo in multi account setup can be difficult to manage with growing account numbers.

Typically Account Vending Machine sits in Management account, though ultimately depends on your multi aws account design.

It use to be the case you needed TF Cloud or Enterprise for landing zones, but the Control Tower Folks added support for OSS. Obviously we’d suggest folks use Cloud (even the free version) as the workflows are better, but it’s noy necessary.

I have used many times

the problem is the name of the resources

I do not know if is possible to add prefixes etc so that resource names are a bit more human readable

but you can script that after the fact

the other issue is that when you want to use modules instead of plain resources you will have to do a lot of terraform state mv commands

but it is the best tool for doing this kind of things

Do you know if AWS has a legacy tool for doing this? I couldn’t find any yet

no they do not

terraform is basically the competitor to Cloudformation

yes, I know that

just last year they seem to partner with hashicorp on CDF efforts and such

humn…

because people uses Tf more

and Google have interest on such tool so that people can , migrate stufff to their cloud

etc

anyhow, the tool is good, do not use the other out there

Note, terraformer just vomits out terraform, be prepared to do a lot of post processing of the generated terraform

the issue is, terraform does not support ANY provider in modules with for_each - this is a TF limitation

in some of our components, we instantiate a module many times with diff providers. Or you can write some code (in bash, Python, etc.) to generate that TF code

but the provider is always the same, is at the root, is the one that should use the module. I don’t need multiple providers…

It should work, but I don’t know why it is using a non-existent provider that I never declare

yes, TF modules implicitly inherit the top-level providers

but is inheriting a provider that I didn’t declare…

I declare

terraform {
  required_providers {
    datadog = {
      source  = "DataDog/datadog"
      version = ">= 3.9.0"
    }
  }
}

And I get

                                │ Could not retrieve the list of available versions for provider
                                │ hashicorp/datadog: provider registry registry.terraform.io does not have a
                                │ provider named registry.terraform.io/hashicorp/datadog

do you also have this ?

provider "datadog" {
  api_key  = local.datadog_api_key
  app_key  = local.datadog_app_key
  validate = local.enabled
}

yes, I have that too

in cases like this, always try to delete

.terraform
.terraform.lock.hcl
/Users/xxxxxx/.terraform.d

might help

Thanks, I’ve already tried that, without success

I found the issue, I had to declare the provider in the module root

terraform {
  required_providers {
    datadog = {
      source  = "DataDog/datadog"
      version = ">= 3.9.0"
    }
  }
}

and the same on the root of my code, but only in the root I can declare the

provider "datadog" {
  api_key = var.datadog_api_key
  app_key = var.datadog_app_key
}

In the module, the provider configuration can’t be there, even if it is in blank like

provider "datadog" {} 

it will fail.

nm I can just add on the rules in the application module I bet

Yup, that would be the way. It does mean that the destruction of resources matters a lot, but that is typically a lesser concern.

https://github.com/cloudposse/terraform-aws-acm-request-certificate/blob/6cce676a316326f3e91edfb53afce4a29c68cba7/main.tf#L12

cc: @Robert Berger

use input subject_alternative_names

Im not clear what you are suggesting. I am using subject_alternative_names (actually passing in a list ["[foo.example.com](http://foo.example.com)"] )

The problem is that when it tries to do the DNS validation, it does it in the zone specified by zone_name ([bar.example.com](http://bar.example.com)) and for it to work it needs to do one validation in there for [foo.bar.example.com](http://foo.bar.example.com) but also needs to do a DNS Validation in zone [example.com](http://example.com)

oh i see, so it might be getting stuck on validating the domain

see https://github.com/cloudposse/terraform-aws-acm-request-certificate/blob/6cce676a316326f3e91edfb53afce4a29c68cba7/main.tf#L50

try setting wait_for_certificate_issued to false

then you could try to update the records for example.org in order to get dns validation to work correctly

That would probably make the run complete but the certificate would never be validated. Like you just said, I guess a work around would be to update the dns validation with a resoruce outside of the terraform-aws-acm-request module, but would somehow need to get the validation values out of the module as well. Looks like that is an output of the module: domain_validation_options

do you think it would be possible to modify the module to allow it to work for your use case ?

or would it be better to disable validation within the module, create the records outside the module, and perform the validation outside the module?

this sounds like it’s worth a ticket, at least, in the repo issues section :)

Well, its “Just software” I suspect its possible, but I’m just ramping my terraform fu. It would take some string processing and some logic to do it in the module. Or possibly have optional input variables that would just tell it what to do. Probably easier to just document this use case and do it outside the module.

I’ll file a ticket this weekend…

i think one issue is that we’d need to know the zone id of the SANs in order to create the record which would get complicated

Thanks for the help. I worked around my immediate block by just dropping the requirement for the alternate name for now.

if the other SANs are in route53, we could allow multiple zone ids to be passed in. that might be one avenue

Yes, if the module would do it, it would need to know maybe the alternate name and the zone for the alternate names

looks like you could also get the validation info as an output from the module too

https://github.com/cloudposse/terraform-aws-acm-request-certificate/blob/6cce676a316326f3e91edfb53afce4a29c68cba7/outputs.tf#L11

Yes, I see that now that could be used to do set up the DNS Validation outside of the acm module

Would have to play with it to see if domain_validation_options would need further processing as it would still have the wrong base zone / dns name for one of the names

oh true. the module would require some refactoring for sure

yep this is the one we use as well

Yeah — I think this is the one everyone uses. Unfortunately, I think the SQL model and Terraform don’t mix well. I have similar sentiments against this provider. I’m not at the point where I’m going to stop using it yet… but I’m close. If there was another option for better managed a PGSQL DB via IaC then I’d go that route.

https://github.com/ariga/atlas maybe this is interesting @Matt Gowie?

@Tyrone Meijn — That’s very interesting, thanks for sharing. I don’t see support for manage roles / users, but if it adds that then I’d be on board.

Odd, these releases generally come on wednesdays!

sounds like you could use the split function or you could use a provider to parse the url

https://github.com/matthewmueller/terraform-provider-url

or regex function

there is a variable to specify the instance type https://github.com/cloudposse/terraform-aws-elasticsearch/blob/master/variables.tf#L55

https://docs.aws.amazon.com/opensearch-service/latest/developerguide/supported-instance-types.html

yes I see that, but those instances take some extra steps to mount the nvme ssd they come with onto the ec2 instance, then it’s another step to make sure the elasticsearch cluster is actually using the nvme

I wonder if the terraform did the heavy lifting in that area already

you can use this working example https://github.com/cloudposse/terraform-aws-elasticsearch/tree/master/examples/complete, specify the instance type and test

Nah it doesn’t, can I add that as a feature request somewhere?

yes, you can open an issue anytime

what it does not do? When you add the instance type, does it throw any errors?

never mind, i had this project confused with something else. This spins up an official aws elasticsearch, not an baremetal elasticsearch on ec2

https://registry.terraform.io/providers/hashicorp/awscc/latest

we also accept prs to the cloudposse aws utils provider https://registry.terraform.io/providers/cloudposse/utils/latest

Thanks @jose.amengual, I didn’t know about awscc! Took a look, but It does not yet support wafv2 web acl.

it worth the try

Yes, looks promising!

@RB I’m not sure it would make sense to add functionality that will be available inside terraform-provider-aws anytime in the future to this provider. Do you think it would fit into this use case?

The PR might take months or years before it’s merged. It might never get merged – there are a lot of good PRs that languish forever because they are too complex and there’s not enough demand.

Because of this, I think the only reasonable approach is to either manage that resource attribute yourself (if you can use lifecycle { ignore_changes }), or completely eject from Terraform for this resource. For example, there might be support in CloudFormation. And as a worst case, clickops it.

Any other approach is going to bitrot over time. And IMO it’s worse to deal with exotic bitrot than to deal with documented clickops.

Good point, so I think I’ll configure the WAF via Cloudformation.

Do you think it would be valid in this case to manage the “aws_cloudformation_stack” through terraform?

the module creates a param group

https://github.com/cloudposse/terraform-aws-rds-cluster/blob/6b63758b58903b8214b97fdd58688c4f4102d04a/main.tf#L272

perhaps you need to modify the cluster family input var to upgrade the db?

yeah, i saw that it’s creating a param group, and even lifecycle is set to create before destroy, so not sure why

i did set cluster family input as well as engine version

can post my module config and terraform plan if that’s helpful

yes please create an issue with a reproducible example and then link to it here

i created an issue here: https://github.com/cloudposse/terraform-aws-rds-cluster/issues/134 i’ll add a comment with my terraform plan output shortly

when you run terraform version, what aws provider version are you using?

i see this issue with the aws provider was resolved in certain 3.63.0

https://github.com/hashicorp/terraform-provider-aws/issues/17357

we were using 3.28.0, but saw that issue you linked - upgrade to 3.64.0 and saw the same error message

just added a comment to my issue with the terraform plan output

thank you for your help

so now you’re using the latest aws version and it’s still giving you the same issue? its possible this could be another bug with the provider then

ah hmm could be. not the latest version of AWS, just the one past where that issue was resolved but i can try later versions of the aws provider and see if that changes anything

we just stick it at the top of main.tf

sometimes it’s also in other files but most of the time we have 4 files: main, outputs, variables, context

I agree with sticking in at the top of the files. For child modules it’s easy to put all the local variables in separate file, for root modules I would also stick to this pattern but in some rare cases improving visibility breaks a context if tightly coupled local is in separate file.

Trade-offs, trade offs

Yea, I think sticking them atop the file they are used is one of the best places. When used by multiple files, sticking them in a [locals.tf](http://locals.tf) would make sense

the tags are the same for all resources created by the module

the tags are not related to name

if you change name, all resources provisioned by the module will have diff IDs/names generated by the label module in the format <namespace>-<environment>-<stage>-<name>

this is by design. name is part of tags. why this is causing a problem?

that is correct, but in this case we can create more than one access point for the same efs file system and it would be nice to be able to name then differently so they have a logical name. As you can see here, all the access points have the same name efs-test

whereas I could name them to data common media if I could

One more consideration, where are the microservices running? e.g. EKS or ECS?