#spacelift (2024-06)

@Dan Miller (Cloud Posse)

The child admin stacks are administrative stacks themselves, but do not manage other administrative stacks. The root admin stack manages only and all administrative stacks across all tenants (or any filter), whereas the child admin stacks manage all stacks within that context filter (plat tenant f.e.)

But that child admin stack itself fits that same context filter for the plat tenant, so that’s why we exclude administrative stacks there. So that it doesnt discover itself

In this case, only the root admin stack creates those other admin stacks. However you can change that to be whatever you’d prefer! But be mindful of how those context filters are configured, since you want to be sure all stacks are managed by exactly 1 admin stack

Also, we have the opposite of context_filters with excluded_context_filters. You can use these 2 together to filter exactly which stacks you want to manage

Thanks @Dan Miller (Cloud Posse), I did consider putting all Spacelift terraform resources under the root admin stack (as is done with spacelift/spaces) but there are cases where placing those resources in stacks under a child “tenant-admin” stack make sense for conceptual grouping.

To crystallise the situation: • We’re keeping the standard refarch structure where possible, (root admin stack –> tenant admins with admin: false –> component stacks) • I have a “core” tenant, with a collection of Spacelift stacks that manage both AWS and Spacelift components in that tenant • Currently I have to disable the workspace setting, and therefore hide from Spacelift, the stacks managing Spacelift resources, as I can’t create administrative component stacks. Filtering within “core” by excluding all other tenants would require maintenance, so does not appeal. There’s no way in the context_filter object to filter by stack label, so I can’t add a label to all the Spacelift stacks and filter based on that + tenants: ["core"]

Proxying a “label filter” via a tag, which can be filtered, would work, but would add a redundant tag to all the AWS resources in the tenant. Is that the best option here?

I think it’s that or hack in exclude-self behaviour into the spacelift admin-stack component (compare the elements of the local.child_stacks map against local.managed_by maybe?)

You could add a tag to only the child admin stacks. Something like this:

components:
  terraform:
    admin-stack:
      metadata:
        component: spacelift/admin-stack
        inherits:
          - admin-stack/default
      settings:
        spacelift:
          space_name: plat
          labels:
            - admin-stack-name:plat
      vars:
        tags:
          spacelift-type: admin # new unique tag for the child admin stacks
        context_filters:
          tenants: ["plat"]
        excluded_context_filters:
          tags:
            spacelift-type: admin # exclude yourself by unique child admin stack tag

You mean OpenTofu, right? ;)

No, and I understand the rationale around licensing, but I’m not interested at the moment in trying to use OpenTofu

I don’t see my choosing to use Terraform >=1.6 in Spacelift as any different from my choosing to use Terraform >=1.6 in Github Actions, for example. As long as it’s my choice of version, and not a specific distribution issue of Spacelift’s choice

Hey spacelift employee here, so I can try and point you in the right direction.

Firstly, I would personally recommend opentofu. (I had to say it as an opentofu dev, sorry!)

But if that’s not what you want then If you contact Spacelift support we will be able to talk through your options and what the possibilities are.

Just for my own personal curiosity is there a specific feature of terraform >=1.6 you’re looking to upgrade for?

There’s some enhancements to evaluation of unknown expressions, where my local execution works great using tf 1.8.4, but fails in a spacelift run using tf 1.5.7. but then i’m very much looking forward to the ephemeral values planned for 1.10…