2 messages
T
Tyler Rankinabout 7 hours ago
We make heavy use of
All Spacelift UI outputs for each of our eks stacks (>20) recently started to display
Throughout the planning phase we have multiple remote-state calls reading cross account values and we observe the workspace changing by checking
It seems like the last remote-state call might be to
All that said our local atmos applies succeed. So I guess the question to the group is has anyone seen an issue with
remote-state, generally v1.8.0. Recently we've encountered an issue with our eks component. We believe there is a piece of this on Spacelift’s end that is causing the issue but was curious if anyone else using remote-state might've observed this behavior. All Spacelift UI outputs for each of our eks stacks (>20) recently started to display
sandbox values. We don't have any corresponding runs that show these being set. The stacks are failing to apply due to a lineage mismatch. Throughout the planning phase we have multiple remote-state calls reading cross account values and we observe the workspace changing by checking
terraform workspace show. I assume this might be normal for the remote-state calls to actually lookup the state values. It seems like the last remote-state call might be to
sandbox, and Spacelift isn't reading .terraform/enviroment a final time after it switches back to workspace of the actual stack we are planning. This causes Spacelift to pull the sandbox state and attempt an apply which fails. While Spacelift UI outputs are incorrect, the state file for each of our eks components are intact and don't have erroneous sandbox values. All that said our local atmos applies succeed. So I guess the question to the group is has anyone seen an issue with
remote-state ever targeting the incorrect workspace at the end of a plan/apply? C
cricketscabout 2 hours ago(edited)
Are folks here reliably able to use manifest rendering via the terraform helm provider? What version of the provider are you using?