#office-hours (2023-07)

Hi! I am not sure if I can join the meeting, but a question I have is: What is the recommended way to remove the existing stacks where in the setting of:

• using atmos to generate vars and backend for each Terraform workspace

• with Atlantis configuration (per repo config) I appreciate any help you can provide.

• with Atlantis configuration (per repo config) Note, we now have GitHub Actions support with general feature convergence with Atlantis. If you’re starting from scratch, I recommend this approach.

Thank you for the update! This is the document, right?

Yes, however, I think we haven’t yet written the integration guide.

@Dan Miller (Cloud Posse) can link you to what we have

https://github.com/cloudposse/github-action-atmos-terraform-plan

https://github.com/cloudposse/github-action-atmos-terraform-apply

The documentation that I’ve written is still in PR review. I’ll link here once it’s published. Should be the EOD today

https://atmos.tools/integrations/github-actions/atmos-terraform-plan

https://atmos.tools/integrations/github-actions/atmos-terraform-apply

Thank you for the update!

interesting product, seems it can be used for disaster recovery

Thank you!

Anytime. Docs are a bit light but if you need any help with either let me know. Happy to jump on a call and walk you through it.

OH, almost forgot. There is something called network mirror that you may want to read up on. It requires modifying your .terraformrc but in theory you could point your terraform applies to use some folder path for all the providers. the .terraformrc is something that the terraform cli will pick up. I believe for TFC it requires self-hosted agents and with spacelift i believe it’s supported.

We never looked at it because we didn’t want to self-hosted agents

will this work in a version controled modules structure ?

for example if I add this to my vpc module that is tagged 1.2.3 and I want to update the providers versions when I will apply the infra for VPC 1.2.3 that will automatically take the latest versions for all the providers, right ?

Yes, I believe it should work in those situations. I’ve personally been using it at the same level as my modules so that if something were to go wrong I could branch the repo (https://github.com/GlueOps/terraform-module-provider-versions) and point back to alternative versions quickly.

so the provider versions module is always used in the other module with the latest version

if i would want to version this module as well, my problem of creating multiple pr’s for each sub module repo will be back to square 1

Yeah, so in my situation we assume that we can move all of our stack together to the latest versions (https://github.com/GlueOps/terraform-module-provider-versions). If one part of our stack has an issue we rollback and keep everything on the older version until we can resolve that issue. One situation where we have had to rollback is with the tfe provider for terraform cloud: https://github.com/GlueOps/terraform-module-provider-versions/blob/main/versions.tf#L43 rather than try and fix the issue we are looking to migrate off to spacelift or another solution.

Also, when we do our updates, we go through all the usages of our modules and ensure a plan works cleanly. We also do a plan before the updates to ensure there is no pending drift/changes.

got it

thanks

so no way for you to create a new env with older providers

I haven’t. Typically at the workspace level (and also at the module level) we output maps, lists, or variables. So its purposefully structured and narrowed scope. Because of this I don’t think there’d be a way to even know if the related resource or attribute is depreciated, at least from the perspective of the workspace calling the remote state (or the calling module).

However, you may be able to write a custom rule with tflint to achieve this?

Steampipe is like the old saw or az interactive, but using sql commands

I try to avoid chained dependencies like that as best as possible. Otherwise using solutions like dependabot, renovate, which can watch private repos for new releases and create a PR for apps that consume them.

Perfect question for today’s special guest.

@Maksym Vlasov

Renovate looks pretty solid. Thanks for setting up this speaker.