#terraform-aws-modules (2021-08)
Terraform Modules
Discussions related to https://github.com/terraform-aws-modules
Archive: https://archive.sweetops.com/terraform-aws-modules/
2021-08-03
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 …
it looks like the issue was a recursive import. did you resolve it ?
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 …
I solved it in my case. I do think it should handle the situation.
@Brian Ojeda thanks for reporting
we did not test situation like that where you import the same file in a stack and in globals.yaml
this is not a realistic case since we don’t need to import globals.yaml
, then vpc
, then the same vpc
in globals
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.
but anyway, thanks for reporting, we need to handle those unrealistic cases anyway
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)
@Brian Ojeda all imports are relative with respect to the current folder
this is ok
import:
- catalog/app-stack/example-app
- catalog/app-stack/foobar-app
- globals
this is ok
import:
- catalog/component/data
- catalog/app-stack/example-app
- catalog/app-stack/foobar-app
- globals
this
# catalog/app-stack/example-app.yaml
import:
- catalog/component/data
should be
# catalog/app-stack/example-app.yaml
import:
- ../component/data
inside each file, imports’ paths are relative
let me know if it works for you, we did not test that scenario with atmos
, just tested it with our provider-utils
we are working on a new atmos now to be the same as the provider
(the current atmos might work differently, did not test hierarchical imports like that)
This is informative. I did notice some differences between the two. It now all makes sense.
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
if you want them to behave the same (and they behave diff with those complex imports), make the imports simpler for now
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”.
2021-08-05
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
and i want to decommission some infrastructure
note, we really don’t use direnv
anymore this way
it wasn’t gitops friendly. it was a pattern really functional only for interactive terminals.
i managed to brute force tear it down eventually
thanks erik
sorry for the delayed response!
2021-08-13
removing from here
2021-08-16
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.
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)
Anyone had the same issue ?
2021-08-19
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.
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…
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…
could you create a ticket with your exact inputs ?
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…
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…
2021-08-20
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.
@Jeremy G (Cloud Posse) should we modify our auto-release to add a suffix to the releases so we can prevent dependabot from updating?
@Dylan checked that dependabot does not support prerelease flags
but it can operate on regexes
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.
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.
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.
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.
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-24
2021-08-25
2021-08-29
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-31
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?
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…