#spacelift (2023-05)

2023-05-01

Tyler Rankin avatar
Tyler Rankin

In an effort to automate in-repo Spacelift stacks, I hope to run the spacelift module after terraform adds the new repo to the Spacelift’s Github App installation of allowed repos. When setting module.spacelift to depend_on the github_app_installation_repositories resource, I’m getting an error that seems to originate within the CloudPosse Spacelift Module (in :thread: ).

Any suggestions on only executing cloudposse/cloud-infrastructure-automation/spacelift after another resource completes?

Tyler Rankin avatar
Tyler Rankin

Cursory looks seems to do with passing toset() to for_each:

module.spacelift.spacelift_policy_attachment.push_administrative[0]: Refreshing state... [id=global-administrative-push-policy/ID]
module.spacelift.spacelift_policy_attachment.trigger_administrative[0]: Refreshing state... [id=global-administrative-trigger-policy/ID]
╷
│ Error: Invalid for_each argument
│ 
│   on .terraform/modules/spacelift/main.tf line 82, in resource "spacelift_policy" "custom":
│   82:   for_each = toset(local.distinct_policy_names)
│     ├────────────────
│     │ local.distinct_policy_names is a list of string, known only after apply
│ 
│ The "for_each" set includes values derived from resource attributes that
│ cannot be determined until apply, and so Terraform cannot determine the
│ full set of keys that will identify the instances of this resource.
│ 
│ When working with unknown values in for_each, it's better to use a map
│ value where the keys are defined statically in your configuration and where
│ only the values contain apply-time results.
│ 
│ Alternatively, you could use the -target planning option to first apply
│ only the resources that the for_each value depends on, and then apply a
│ second time to fully converge.
╵
[RunID] Unexpected exit code when planning changes: 1
Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

We have a pretty opinionated implementation of Spacelift. It’s designed predominantly to work with atmos

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

@Tyler Rankin are you planning on using atmos?

Tyler Rankin avatar
Tyler Rankin

Yes, in fact we do use Atmos as well. My hope was to add the Github resource to our module which would ensure the in-repo terraform repository has been added to the Spacelift Github App allow list. Otherwise, the stack could fail if the Github App can’t access the repo when module.spacelift actually provisions the new stack.

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Aha, cool!

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

So I believe the depend_on stuff was recently worked on by @Jeremy White (Cloud Posse)

1
Tyler Rankin avatar
Tyler Rankin

@Andriy Knysh (Cloud Posse) also let me know that there may be changes coming to the Spacelift module. I hope those changes aren’t too far out and might add support for using depends_on with it

1
Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Transferring this to a private channel.

Jeremy White (Cloud Posse) avatar
Jeremy White (Cloud Posse)
11:35:57 PM

@Jeremy White (Cloud Posse) has joined the channel

2023-05-02

2023-05-03

2023-05-18

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Thoughts on splitting this channel into spacelift-announcements and spacelift? The blog posts drownout any conversation.

1
 avatar

I think it’s a great idea

2023-05-26

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Ok, I’ve moved the blog posts to spacelift-announcements

1
1
Alex Jurkiewicz avatar
Alex Jurkiewicz

dang, we missed https://sweetops.slack.com/archives/C059RSPA22W/p1685539845134769 where they went purely ChatGPT

Scaling AWS Infrastructure – Tools and Features Learn about how to scale your AWS infrastructure. See the tools and features that are perfect for effective scaling.

2023-05-29

2023-05-30

Phil Hadviger avatar
Phil Hadviger

We’re starting to finally do drift detection with Spacelift, just using the default built-in drift detection they offer on private workers. I was curious if any of you use different drift detection tools with Spacelift, and if so, if those tools support provider aliasing and multi-account/region stacks.

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Could you provide an example?

Phil Hadviger avatar
Phil Hadviger

An example of a terraform stack with alias providers?

provider "aws" {
  alias  = "prod_use1"
  region = "us-east-1"
}
provider "aws" {
  alias  = "prod_euw1"
  region = "eu-west-1"
}

I was mainly asking if people here are generally just using Spacelift’s provided drift detection or other tools like driftctl? I was personally really interested in driftctl, but it has these restrictions. https://docs.driftctl.com/0.34.0/limitations/#aws-regions--credentials-limits like not being able to work with stacks that have alias providers.

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Aha, yes, makes sense. We’re aware of Driftctl, but for the aforementioned reasons haven’t really invested in it. The scheduled plans (aka drift detection) in Spacelift offer 80% of the benefits with 20% of the effort, so to say. Of course it doesn’t tell you what’s not under IaC, but it does catch everything that’s in IaC but no longer reconciling with what’s deployed.

1
Phil Hadviger avatar
Phil Hadviger

Thanks, I appreciate the info!

2023-05-31

    keyboard_arrow_up