#office-hours - October 2024

23 messages

Public "Office Hours" are held every Wednesday at 11:30 PST via Zoom. It's open to everyone. Ask questions related to DevOps & Cloud and get answers!
👉️ https://cpco.io/slack-office-hours

October 2024
erik
erikabout 2 years ago
@here office hours is starting in 30 minutes! Remember to post your questions here.
Zapier
Zapierabout 2 years ago(edited)
managedkaos
managedkaosabout 2 years ago
erik
erikabout 2 years ago
@here office hours is starting in 30 minutes! Remember to post your questions here.
Zapier
Zapierabout 2 years ago(edited)
PePe Amengual
PePe Amengualabout 2 years ago
@Erik Osterman (Cloud Posse), you were right about Atlantis the first time, we did move to the CNCF github already, now is Slack and other things, we even added Fossa and Snyk and Dosu to our repos
Jonathan Eunice
Jonathan Euniceabout 2 years ago
Just watched a bit of the HashiCorp live cast. Much to talk about there, but the “scaling up Terraform” with components, modules, and workflows seems to recapitulate Cloud Posse’s journey and solutions/approaches. Can’t wait to hear @Erik Osterman (Cloud Posse)’s take. Also, “deferred changes” seems magical but could be a train wreck, so… you’re up, Erik!
Michael
Michaelabout 2 years ago
Rishav
Rishavabout 2 years ago
Outta curiosity, how does one submit a topic or two for the office-hour? Be keen to see/hear a few highlights from the HashiConf as well.
erik
erikabout 2 years ago
@here office hours is starting in 30 minutes! Remember to post your questions here.
Zapier
Zapierabout 2 years ago(edited)
Rishav
Rishavabout 2 years ago
Many thanks for sharing your space at the last Office Hours, @Erik Osterman (Cloud Posse) et al, genuinely appreciate the time.

I brought a fair few Qs about Terraform provisioning pipelines with GitHub Action, to which you added plenty of depth and potential pitfalls to look out for.

Summarize plan outline
• Reviewing 1000s of lines of planned changes is simply not feasible, but a brief 1-liner like "Plan: 2 to add, 2 to change, 2 to destroy" fails to convey the scope of impact.
• A "middle-ground" outline would be preferable, which accounts for character limits within PR comments, while linking to the complete output log in the workflow job summary.
Plan file reuse with encryption
• Too often PRs are merged with apply -auto-approve, which is optimistic at best, but liable to configuration drift from changes made outside the workflow.
• While it's best practice to reuse the plan file from plan command, storing and retrieving it between workflow runs isn't easy, let alone if it contains sensitive data.
Apply before OR after merge
• Whenever we choose to apply changes, we need a way to uniquely identify and fetch the appropriate plan file outside of pull_request context.
• In addition to push and pull_request_target events, support GitHub's native merge queue feature to conditionally merge the PR only if it applies successfully.
As promised, I managed to wrangle out a few hours over the weekend to pour over these problems, and address each one in turn. Drawn up my progress in a blog post—happy to share, if you'd like? (keen to not fall foul of any self-promotion rules!)
erik
erikabout 2 years ago
@here office hours is starting in 30 minutes! Remember to post your questions here.
Matthew Clark
Matthew Clarkabout 2 years ago
When running atmos commands to apply the first time, it fails due to "account already belonging to organization", unless we set organization_enabled to false in accounts component in catalog stack. If we set this to false, it runs - we then just renamed the existing management account to core-root. Is core-root referencing the management account, or is there an expectation that core-root is another separate account? Once we get past that - the OUs/accounts exist, but when we apply account-settings it's implying the the account_name doesn't exist in local.account_org_role_arns. In your experience, is this likely an issue with what I mention above re: organizations, something running in the wrong workspace and by proxy not having access to the intended tfstate, or something else?

This error is occurring in the account-map IAM roles module which is pulling from full account map from account map module.

full_account_map = {
  "core-artifacts" = "<REDACTED>"
  "core-audit" = "<REDACTED>"
  "core-dns" = "<REDACTED>"
  "core-identity" = "<REDACTED>"
  "core-root" = "<REDACTED>"
}

How would we go about debugging this? Still working our way around atmos, heh.
Bob Berg
Bob Bergabout 2 years ago
Could I get help on a PR review?

I previously opened an issue and flagged it as a bug, this was in August, https://github.com/cloudposse/terraform-datadog-platform/issues/100.

I submitted a pull request to fix said issue this past Monday, https://github.com/cloudposse/terraform-datadog-platform/pull/107.

Could I get some direction on where to take this and how to get it approved? It was a simple one-line-change that fixed the issue.
Zapier
Zapierabout 2 years ago(edited)
erik
erikabout 2 years ago
@here office hours is starting in 30 minutes! Remember to post your questions here.