#terraform-aws-modules (2021-08)

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

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”.

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.

https://docs.cloudposse.com/tutorials/atmos-getting-started/

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

i managed to brute force tear it down eventually

thanks erik

sorry for the delayed response!

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)

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

could you create a ticket with your exact inputs ?

Ok, will do that.

@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.