#geodesic (2021-05)
Discussions related to https://github.com/cloudposse/geodesic
Archive: https://archive.sweetops.com/geodesic/
2021-05-01
2021-05-02
![marc slayton avatar](https://secure.gravatar.com/avatar/2f6bef790be25974520ab3d11e162d22.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0002-72.png)
RE: Atmos – kudos to you @Joe Hosteny for your advice today in getting my Atmos compiles going. Everything works now. Cheers –
2021-05-03
2021-05-04
2021-05-05
![Joe Hosteny avatar](https://secure.gravatar.com/avatar/851f2d21e357fbb172c3abfc9860d9c5.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0015-72.png)
Hi all, I had some more time to work on our account conversion today. I got to the dns-primary
component, but I seem to be missing something now. What is the expectation for how to run non-bootstrap terraform plan / apply for the non-bootstrap components using the terraform profiles, rather than the org role ARNs (I am looking at the all-new-components
branch)? For example, it was easy for the iam-delegated-roles
, as that component’s provider performs an assume_role
into the destination account. Is there a short blurb that gives a high level view of how things are to fit together?
![Joe Hosteny avatar](https://secure.gravatar.com/avatar/851f2d21e357fbb172c3abfc9860d9c5.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0015-72.png)
Specifically, I kind of blindly configured the stack and started a run, then was surprised to see the zones appearing in the root account. That’s when I noticed that the component was using the named terraform profile (or named terraform role ARN on master)
![Matt Gowie avatar](https://avatars.slack-edge.com/2023-02-06/4762019351860_44dadfaff89f62cba646_72.jpg)
@Joe Hosteny the current status of assume_role vs profile is a bit in flux. I know Cloud Posse folks are moving towards using profiles for everything since that covers some issue that they were having that I’m not 100% up-to-speed on.
I personally had issues with this so I created a potential abstract aws-provider.tf proposal which is up on PR: https://github.com/cloudposse/terraform-aws-components/pull/322
Does that possibly help you if it were used more widespread through out the components?
what Proposes a new pattern for abstractly defining the aws provider via a common providers.tf why This enables usage of the following types of AWS auth for components: Environment credentials …
![Joe Hosteny avatar](https://secure.gravatar.com/avatar/851f2d21e357fbb172c3abfc9860d9c5.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0015-72.png)
Thanks @Matt Gowie. I will take a look at this.
![Joe Hosteny avatar](https://secure.gravatar.com/avatar/851f2d21e357fbb172c3abfc9860d9c5.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0015-72.png)
Are you just using an IAM user that is able to assume the *-terraform role in the identity account?
![Joe Hosteny avatar](https://secure.gravatar.com/avatar/851f2d21e357fbb172c3abfc9860d9c5.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0015-72.png)
@Matt Gowie FYI, I was able to finally get this to work (deployed DNS primary stack in the dns
account using the proper terraform
role). It was death by a thousand papercuts, but I think I have it all down now.
![Joe Hosteny avatar](https://secure.gravatar.com/avatar/851f2d21e357fbb172c3abfc9860d9c5.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0015-72.png)
And by papercuts, I mean my mistakes
![Joe Hosteny avatar](https://secure.gravatar.com/avatar/851f2d21e357fbb172c3abfc9860d9c5.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0015-72.png)
This was done via a login for a user, not system account, provisioned via GSuite and using SAML SSO. I did use the terraform_profile_name
too, not the dynamic assume role. It fell into place once I was able to figure out how to get the iam-delegated-roles
to deploy in root
![Matt Gowie avatar](https://avatars.slack-edge.com/2023-02-06/4762019351860_44dadfaff89f62cba646_72.jpg)
Ah sorry I didn’t see your other reply Joe. Glad you got it figured. Sorry I can’t be of much help — I’m not utilizing this 100% yet, just piecemeal so I don’t use the IAM roles stuff unfortunately.
![Joe Hosteny avatar](https://secure.gravatar.com/avatar/851f2d21e357fbb172c3abfc9860d9c5.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0015-72.png)
No worries! I realize I am working on it probably a little too early anyway.
2021-05-07
2021-05-10
2021-05-25
![Brian Ojeda avatar](https://avatars.slack-edge.com/2021-05-21/2091552027955_105f68e1608ac63c274a_72.jpg)
Is tfstate now being saved only in in the root account even in a multi-account and multi-region setup? That is what I am understanding based on terraform-aws-components
branch upstream-account-comps
.
![Matt Gowie avatar](https://avatars.slack-edge.com/2023-02-06/4762019351860_44dadfaff89f62cba646_72.jpg)
Yeah, that’s the pattern going forward. One tfstate bucket with each component workspace separated using ‘workspace_key_prefix’.
![Brian Ojeda avatar](https://avatars.slack-edge.com/2021-05-21/2091552027955_105f68e1608ac63c274a_72.jpg)
Thank you. Follow up question, would that allow us to run terraform
to do region failover if s3 (and ddb) in the region with bucket is down?
![Matt Gowie avatar](https://avatars.slack-edge.com/2023-02-06/4762019351860_44dadfaff89f62cba646_72.jpg)
Good question… I’m not 100%. S3 has 9s out to wazoo, so I’m not sure that is a much of a concern but it’s likely worth looking into. If DDB is down then you can skip the lock I believe.
![Brian Ojeda avatar](https://avatars.slack-edge.com/2021-05-21/2091552027955_105f68e1608ac63c274a_72.jpg)
You see any issues maintaining a replica s3 and ddb in another region? If a failure does occur, we could set a variable to switch to the failover state bucket and ddb.
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
Yea, so what we did was add support to our state bucket module to replicate the state to a backup region
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
In the failover scenario, we would flip to using the backup bucket
![Brian Ojeda avatar](https://avatars.slack-edge.com/2021-05-21/2091552027955_105f68e1608ac63c274a_72.jpg)
Sweet. That’s what I figure.
2021-05-26
2021-05-27
![Brian Ojeda avatar](https://avatars.slack-edge.com/2021-05-21/2091552027955_105f68e1608ac63c274a_72.jpg)
Is it possible to have multiple components based on the same component? Let’s say I wanted multiple vpcs defined in the same stack? I don’t want to create a unique root module direct for each vpc that duplicates the code.
![Joe Hosteny avatar](https://secure.gravatar.com/avatar/851f2d21e357fbb172c3abfc9860d9c5.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0015-72.png)
I think this should be pretty straightforward once the vendir
PR is completed. This should allow you to copy the upstream component into multiple locations locally, with different configs.
Issue: #37 Created a function that will copy existing files listed in the destination directory to the staging area prior to deletion preserving the content. I felt that pulling the content into th…
![Matt Gowie avatar](https://avatars.slack-edge.com/2023-02-06/4762019351860_44dadfaff89f62cba646_72.jpg)
@Brian Ojeda check out https://docs.cloudposse.com/reference/stacks/#component-inheritance
![Brian Ojeda avatar](https://avatars.slack-edge.com/2021-05-21/2091552027955_105f68e1608ac63c274a_72.jpg)
That’s perfect!
![Joe Hosteny avatar](https://secure.gravatar.com/avatar/851f2d21e357fbb172c3abfc9860d9c5.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0015-72.png)
Oh slick. So in that example, vendir would download to s3-bucket
?
![Matt Gowie avatar](https://avatars.slack-edge.com/2023-02-06/4762019351860_44dadfaff89f62cba646_72.jpg)
Vendir is earlier on in the lifecycle in this case. Component inheritence comes into play when you have a single component folder and you want to utilize that component multiple times in a particular stack.
![Joe Hosteny avatar](https://secure.gravatar.com/avatar/851f2d21e357fbb172c3abfc9860d9c5.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0015-72.png)
Right - I think that is what I was envisioning. My prior suggestion was that you would use vendir to download to two locations, components/terraform/public-images
and components/terraform/export-data
in this case. But this is better!
![Matt Gowie avatar](https://avatars.slack-edge.com/2023-02-06/4762019351860_44dadfaff89f62cba646_72.jpg)
Yeah this is one of the more advanced bits that’s a nicely hidden unless you find this documentation.
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
oh that’s rad! I didn’t see that someone opened that PR.
![Joe Hosteny avatar](https://secure.gravatar.com/avatar/851f2d21e357fbb172c3abfc9860d9c5.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0015-72.png)
Hi @Erik Osterman (Cloud Posse), yeah, that was someone on my team, We’re waiting for a review on one more point and also someone to sign off on the contributor agreement. But I’ve been using it locally.
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
ohhhhhhhh rad! thanks Joe
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
cc: @Andriy Knysh (Cloud Posse)
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
yep I saw the PR, thanks @Joe Hosteny