#terraform-aws-modules (2021-08)

terraform Terraform Modules

Discussions related to https://github.com/terraform-aws-modules Archive: https://archive.sweetops.com/terraform-aws-modules/

2021-08-31

Manuel Morejón avatar
Manuel Morejón

Hi team! Nice to be here with you. I’m facing this issue https://github.com/cloudposse/terraform-aws-elasticsearch/issues/57 Do you have any suggestion to resolve it?

IAM Policy cannot be created due to InvalidTypeException · Issue #57 · cloudposse/terraform-aws-elasticsearch attachment image

Describe the Bug ES was created without iam_role_arns. After adding it and applying it failed with: module.elasticsearch.aws_iam_role.elasticsearch_user[0]: Creating… module.elasticsearch.aws_iam…

2021-08-29

Alex Jurkiewicz avatar
Alex Jurkiewicz

It doesn’t seem like it’s possible to view Bridgecrew security analysis results on pull requests any more. I submitted https://github.com/cloudposse/terraform-aws-rds-cluster/pull/119 and clicking the Bridgecrew link: https://www.bridgecrew.cloud/projects?repository=cloudposse/terraform-aws-rds-cluster&branch=119_ignore-admin-creds&runId=latest I was prompted to login, I used by Github credentials and get redirected to this page: https://www.bridgecrew.cloud/organization Which simply asks me to set a permanent organisation name.

2021-08-25

2021-08-24

2021-08-20

Jeremy (Cloud Posse) avatar
Jeremy (Cloud Posse)

We have just released a new version of null-label, which has triggered updates to virtually all of our Terraform modules. • Please wait to update your modules until you have a reason to. This is not a bugfix release. It has some new features to support “tenants” that are only needed by a very few people. It has a new feature to deconflict tags with the new AWS provider’s default_tags , so if you hare having problems with that, then that is a reason to update your root module to use the new [context.tf](http://context.tf). Otherwise, you can wait, and probably should wait, so we can fix any bugs that may surface.

• The update triggered automatic updates of modules that were in a pre-release state because they were not backward compatible and were going to have another round of breaking changes published. Unfortunately, the automatic updates triggered normal releases (not pre-releases) that got pushed to the Terraform registry. These new releases remain incompatible and should not be adopted. Sorry for the false alert.

• As a general rule we work hard to preserve backward compatibility and we prominently note when there is a breaking change. If you find breaking changes without mention in the release notes, that is definitely a problem. Right now, because of the quantity of changes, it will take us a while to triage and fix whatever comes up, so please simply roll back to an earlier version if the current version is not working for you.

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

@Jeremy (Cloud Posse) should we modify our auto-release to add a suffix to the releases so we can prevent dependabot from updating?

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

@Dylan checked that dependabot does not support prerelease flags

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

but it can operate on regexes

Jeremy (Cloud Posse) avatar
Jeremy (Cloud Posse)

The trouble we are currently having is more complex. We made releases which we later changed to pre-releases because, well, we made a mistake in releasing them in the first place.

Jeremy (Cloud Posse) avatar
Jeremy (Cloud Posse)

Our bots automatically publish patch releases. AFAIK they do not support patching the latest release, they only support patching master and releasing a full release.

Jeremy (Cloud Posse) avatar
Jeremy (Cloud Posse)

So when we have master in a pre-release state and our bot updates [context.tf](http://context.tf), it just changes master and puts out a full release based on the pre-release.

Jeremy (Cloud Posse) avatar
Jeremy (Cloud Posse)

If we were to do pre-releases properly, we would release pre-releases on a pre-release branch and with a pre-release Semantic Version tag. Then the bots would work the way we want.

Jeremy (Cloud Posse) avatar
Jeremy (Cloud Posse)

Our current batch of pre-releases are not really pre-releases, they are failed branches. We (or at least I) thought we would just do proper upgrades and full releases in short order, but obviously it is taking longer. Then next plan is to revert modules to the latest good release, apply subsequent good PRs, and create a new release at the head of the master branch. I authorized nitrocode to do this for terraform-aws-ecs-alb-service-task and think this is how we should unblock module that need unblocking. The trick is to be very careful about the PRs we accept and apply, because some of them build on or fix problems with the stuff we are rolling back. So they need to be carefully vetted.

2021-08-19

Desire BANSE avatar
Desire BANSE

Hi everyone. Is there a guide on how to use https://github.com/cloudposse/terraform-aws-config ? I’m started with https://github.com/cloudposse/terraform-aws-config/tree/master/examples/cis, but getting some errors like The argument "role_arn" is required, but no definition was found.

GitHub - cloudposse/terraform-aws-config: This module configures AWS Config, a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. attachment image

This module configures AWS Config, a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. - GitHub - cloudposse/terraform-aws-config: This module config…

terraform-aws-config/examples/cis at master · cloudposse/terraform-aws-config attachment image

This module configures AWS Config, a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. - terraform-aws-config/examples/cis at master · cloudposse/ter…

RB (Ronak) (Cloud Posse) avatar
RB (Ronak) (Cloud Posse)

could you create a ticket with your exact inputs ?

GitHub - cloudposse/terraform-aws-config: This module configures AWS Config, a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. attachment image

This module configures AWS Config, a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. - GitHub - cloudposse/terraform-aws-config: This module config…

terraform-aws-config/examples/cis at master · cloudposse/terraform-aws-config attachment image

This module configures AWS Config, a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. - terraform-aws-config/examples/cis at master · cloudposse/ter…

Desire BANSE avatar
Desire BANSE

Ok, will do that.

1

2021-08-16

Desire BANSE avatar
Desire BANSE

Hello. On terraform 1.0.4, the terraform-aws-config is raising this issue

│   on .terraform/modules/aws_config_storage.storage.this/versions.tf line 2, in terraform:
│    2:   required_version = ">= 0.12.0, < 0.14.0"
│
│ Module module.aws_config_storage.module.storage.module.this (from git::<https://github.com/cloudposse/terraform-null-label.git?ref=tags/0.19.2>) does not support Terraform
│ version 1.0.4. To proceed, either choose another supported Terraform version or update this version constraint. Version constraints are normally set for good reason, so
│ updating the constraint may lead to other errors or unexpected behavior.
Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

aws_config_storage needs to be updated to remove the upper limit < 0.14.0 - CloudPosse modules does not have upper limits on module/provider versions (not sure why this module has it, might be a mistake)

1
Desire BANSE avatar
Desire BANSE

Thanks! I removed the limit locally, and the issue is gone.

1
Desire BANSE avatar
Desire BANSE

Anyone had the same issue ?

2021-08-13

Amit Karpe avatar
Amit Karpe

removing from here

2021-08-05

jack fenton avatar
jack fenton

hey guys, how do I get atlantis to point to nothing (i.e. plan to destroy everything) we use export TF_CLI_INIT_FROM_MODULE=git::<https://github.com/>....

with

source_up
use envrc
use terraform
use tfenv
jack fenton avatar
jack fenton

and i want to decommission some infrastructure

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

note, we really don’t use direnv anymore this way

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

it wasn’t gitops friendly. it was a pattern really functional only for interactive terminals.

jack fenton avatar
jack fenton

hopefully we’re not using like that anymore too, this is old

1
jack fenton avatar
jack fenton

i managed to brute force tear it down eventually

jack fenton avatar
jack fenton

thanks erik

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

sorry for the delayed response!

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

jack fenton avatar
jack fenton

2021-08-03

Brian Ojeda avatar
Brian Ojeda
Infinite Loop Dag Walk for Remote State Module pinned to v0.12 · Issue #51 · cloudposse/terraform-provider-utils attachment image

Describe the Bug With the v0.12, there is now a bug that causes an infinite loop of dag/walk: vertex (via trace tf logging). The tracing logging show it is waiting on something from X (fill in the …

RB (Ronak) (Cloud Posse) avatar
RB (Ronak) (Cloud Posse)

it looks like the issue was a recursive import. did you resolve it ?

Infinite Loop Dag Walk for Remote State Module pinned to v0.12 · Issue #51 · cloudposse/terraform-provider-utils attachment image

Describe the Bug With the v0.12, there is now a bug that causes an infinite loop of dag/walk: vertex (via trace tf logging). The tracing logging show it is waiting on something from X (fill in the …

Brian Ojeda avatar
Brian Ojeda

I solved it in my case. I do think it should handle the situation.

Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

@ thanks for reporting

Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

we did not test situation like that where you import the same file in a stack and in globals.yaml

Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

this is not a realistic case since we don’t need to import globals.yaml, then vpc, then the same vpc in globals

Brian Ojeda avatar
Brian Ojeda

No problem. I only thought to test it once I understood the changes introduced with v0.12. Made some sense it could be the problem.

Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

but anyway, thanks for reporting, we need to handle those unrealistic cases anyway

Brian Ojeda avatar
Brian Ojeda

I am curious now. If I understand correctly, you imply the pattern that caused the issue is not a valid pattern. So now I am wondering if I am doing something incorrectly? Given the following files as describe in the gist, should it work? It should allow me to do…

atmos terraform deploy foobar-rds -s use1-dev
atmos terraform deploy foobar-rds -s use1-prod
#... (or define groups the related components and call workflows)
Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

@ all imports are relative with respect to the current folder

Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

this is ok

import:
    - catalog/app-stack/example-app
    - catalog/app-stack/foobar-app
    - globals
Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

this is ok

import:
    - catalog/component/data 
    - catalog/app-stack/example-app
    - catalog/app-stack/foobar-app
    - globals
Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

this

# catalog/app-stack/example-app.yaml

import:
  - catalog/component/data
Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

should be

# catalog/app-stack/example-app.yaml

import:
  - ../component/data
Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

inside each file, imports’ paths are relative

Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

let me know if it works for you, we did not test that scenario with atmos, just tested it with our provider-utils

Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

we are working on a new atmos now to be the same as the provider

Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

(the current atmos might work differently, did not test hierarchical imports like that)

Brian Ojeda avatar
Brian Ojeda

This is informative. I did notice some differences between the two. It now all makes sense.

Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

we are rewriting atmos in Go uisng the same code as the TF provider, so they will be the same. Not sure about ETA, we are working on it as time permits

Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

if you want them to behave the same (and they behave diff with those complex imports), make the imports simpler for now

Brian Ojeda avatar
Brian Ojeda

Not in a rush. Right now, my imports are simply. Mostly because I couldn’t figure out why merging didn’t work as expected (you just explained why).

I found this issue by mistake because I didn’t mean import the same stack twice because I was keeping all imports at the top level. However, I had plans to reorganize the stacks and do something more complex when I had time to figure out why it wasn’t working as expect. Previously, it wouldn’t hang, but it didn’t merge as you might expect.

Anyways… All of this is explained by the different yaml “providers”.

    keyboard_arrow_up