Skip dependencies at runtime

Terraspace
#1

Hello,

Would anyone know how to skip dependency resolution at terraspace runtime ?
i.e. I have stack(s) explicitly dependent on other stack(s) via depends_on-helper. While mandatory for the initial terraspace up, it gets in the way of reducing execution times for subsequent runs. So I am hoping a command line option could be passed to skip dependencies resolution on demand.

Example:

  • velero depends on prometheus-stack
  • which depends on aws-ebs-csi-driver
  • which depends on external-snapshotter
  • which depends on kube-base

The order must be respected on initial terraspace up, or some stack will fail due to missing resources provided by parent stack(s).

terraspace up velero
Will run:
    terraspace up kube-base            # batch 1
    terraspace up external-snapshotter # batch 2
    terraspace up aws-ebs-csi-driver   # batch 3
    terraspace up prometheus-stack     # batch 4
    terraspace up velero               # batch 5

But on subsequent runs, it would save precious time to be able to skip the runs on parent stacks. Something like:

terraspace up velero --skip-dependencies
Will run:
    terraspace up velero            # batch 1

I did not find an answer in the docs, apart from the following:

Terraspace always evaluates all layered tfvars files at terraspace compile time. This means helpers like output and depends_on will always register the dependencies with Terraspace if they are called.
Source: Dependencies Tfvars Considerations - Terraspace

leading me to think this might not be doable :cry:

#2

Interesting, currently not doable. Don’t think it’ll be too bad to add though. Would like this ability. Will take a look. Unsure when. Will also review and consider PRs. Of course, no sweat either way :+1:

1 Like
#3

As a follow up, I recently discovered that dependent stacks cannot be reliably interacted with in parallel due to overlapping caching.

If we go back to the above example:

  • velero depends on prometheus-stack
  • prometheus-stack depends on aws-ebs-csi-driver
  • aws-ebs-csi-driver depends on external-snapshotter
  • external-snapshotter depends on kube-base

If one was to run:

for stack in aws-ebs-csi-driver velero prometheus-stack external-snapshotter; do
  for resource in data.aws_region.current data.aws_caller_identity.current; do
    terraspace state rm $stack $resource &
 done
done

it would result in .terraspace-cache directory getting written/overwritten by all stacks at the same time (due to dependent stacks re-running init on their parent(s)), leading to various nasty errors like:

│ Error: Unreadable module directory
│
│ Unable to evaluate directory symlink: lstat
│ ../../modules/xxxxx: no such file or directory

open3.rb:221:in `spawn': No such file or directory - /test/.terraspace-cache/us-east-1/test/stacks/xxxx (Errno::ENOENT)

I think an explicit --skip-dependencies would circumvent it.

EDIT: I take that back, it seems that the entire :CACHE_ROOT/:ENV is what being overwritten by parallel runs. Here is what I ended up with to allow for concurrent runs:

config/app.rb

Terraspace.configure do |config|
  if ENV['TS_EXTRA'].nil?
    config.build.cache_dir = ":CACHE_ROOT/:ENV/:BUILD_DIR"
  else
    config.build.cache_dir = ":CACHE_ROOT/:ENV-#{ENV['TS_EXTRA']}/:BUILD_DIR"
  end
end

for stack in aws-ebs-csi-driver velero prometheus-stack external-snapshotter; do
  for resource in data.aws_region.current data.aws_caller_identity.current; do
    TS_EXTRA=$stack terraspace state rm $stack $resource &
 done
done

Effectively jailing each $env-$stack combination to its own cache directory under :CACHE_ROOT.