It sounds like you see the issue consistently vs intermittently which what was guessing was happening above.
terraform state pull > /tmp/terraspace/remote_state/stacks/d1/state.json
IE: The file is only zero-byte at the very beginning until the terraform state pull command remotely fetches the info.
If it’s consistently a zero-byte file, unsure why then Since Ruby is an interpreted language, you can add debugging puts in the library code itself: https://github.com/boltops-tools/terraspace/blob/master/lib/terraspace/terraform/remote_state/fetcher.rb#L66 Maybe double-check the backend.tf and add a debugging puts like this:
system "cd #{@child.cache_dir} && cat backend.tf" # <= ADD THIS LINE
command = "cd #{@child.cache_dir} && terraform state pull > #{state_path}"
To figure out where terraspace is installed:
bundle info terraspace --path
Also, enable log debug level in
config/app.rb
Terraspace.configure do |config|
config.logger.level = :debug
end
Also, hoping to get a repo with a reproduction of the issue like in this post: Plan stack trace error after making change to existing infra That’ll give us a better fighting chance to figure out what’s going on.
Also, made some pretty big changes to how terraspace all
building and processing works in terrspace 1.1. Wondering when you get a chance you can also give terraspace 1.1 a try. So:
- Hoping to get a repo that helps reproduce the issue
Using
random_pet
resources are nice because they are quick to create. Here are starter examples https://github.com/boltops-tools/terraspace-graph-demo and https://github.com/tongueroo/terraspace-graph-demo-nil-parent - Give terraspace 1.1 a try